6 ms·

import os.path as p Renaming imports to single letters bugs me. I went to see where it's used, and it isn't. Binding pyflakes to Cmd+S in TextMate was the best

import os.path as p Renaming imports to single letters bugs me. I went to see where it's used, and it isn't. Binding pyflakes to Cmd+S in TextMate was the best thing I ever did, and it would have caught this. pyflakes is seriously awesome in that role, and pylint before committing. I'm also surprised that simplejson is used, instead of the built-in json in Python 2.6 and up. A good solution is: try: import json except ImportError: import simplejson as json

masklinn 15y ago
> I'm also surprised that simplejson is used 2.6's json lacks simplejson's C accelerators [0] which makes it roughly 20 times slower than simplejson (2.7's simplejson is also ~50% slower than simplejson, as new performance optimizations were added in 2.1.0, as well as memoizations). Simplejson is also updated more often, which lead to it having less bugs, and interesting new features (the ability to natively serialize decimals was added in 2.1 for instance) simplejson should be the preferred import, with json as a fallback if available. [0] 2.6's json is simplejson 1.9; 2.7's is 2.0.9; the latest release of simplejson is 2.1.3 and 2.1.4 is in preparation
- jedsmith 15y ago
  I elect to stick with the standard library in all cases, so I know how my software will perform everywhere without a redundant external dependency. Sticking with the standard library means you'll eventually get those improvements, too.
  - bretthoerner 15y ago
    > a redundant external dependency Is pip install that hard? Surely any deployed project is already managing a requirements.txt/buildout/setup.py/etc. > means you'll eventually get those improvements The C speedup extension for simplejson existed well before it was merged into Python stdlib as "json". Are you so sure you'll eventually get said improvement?
  - masklinn 15y ago
    > Sticking with the standard library means you'll eventually get those improvements, too. Not in 2.x, you won't.
  - wladimir 15y ago
    Best of both worlds would be to try to import simplejson, and if that fails, fall back to the standard library json. As they have the same interface, that's trivial to do.

masklinn 15y ago

> I'm also surprised that simplejson is used 2.6's json lacks simplejson's C accelerators [0] which makes it roughly 20 times slower than simplejson (2.7's simplejson is also ~50% slower than simplejson, as new performance optimizations were added in 2.1.0, as well as memoizations). Simplejson is also updated more often, which lead to it having less bugs, and interesting new features (the ability to natively serialize decimals was added in 2.1 for instance) simplejson should be the preferred import, with json as a fallback if available. [0] 2.6's json is simplejson 1.9; 2.7's is 2.0.9; the latest release of simplejson is 2.1.3 and 2.1.4 is in preparation

jedsmith 15y ago
I elect to stick with the standard library in all cases, so I know how my software will perform everywhere without a redundant external dependency. Sticking with the standard library means you'll eventually get those improvements, too.
- bretthoerner 15y ago
  > a redundant external dependency Is pip install that hard? Surely any deployed project is already managing a requirements.txt/buildout/setup.py/etc. > means you'll eventually get those improvements The C speedup extension for simplejson existed well before it was merged into Python stdlib as "json". Are you so sure you'll eventually get said improvement?
- masklinn 15y ago
  > Sticking with the standard library means you'll eventually get those improvements, too. Not in 2.x, you won't.
- wladimir 15y ago
  Best of both worlds would be to try to import simplejson, and if that fails, fall back to the standard library json. As they have the same interface, that's trivial to do.