'import six' can be after its first use

[daira]

$ cat test.py
u"artificial example"
import sys

$ python-modernize --six-unicode test.py
[...]
@@ -1,2 +1,3 @@
-u"artificial example"
+six.u("artificial example")
 import sys
+import six

which doesn't work because the import of six is after the first use.

(moved from mitsuhiko/python-modernize#20 )

[daira]

A test is on the https://github.com/python-modernize/python-modernize/commits/19-import-after-use branch.

[takluyver]

Looks like the bug is actually in lib2to3.fixer_utils.touch_import.

[daira]

This seems relevant: http://bugs.python.org/issue14282

[daira]

Yes, I think adding imports after existing ones is wrong in general. Imports added by python-modernize should go:

• after existing __future__ imports, if any
• otherwise, after the module docstring, if any
• otherwise, after any initial lines that are either blank or start with #.

(See also #18.)

[daira]

According to grep -Rn --include='*.py' touch_import /usr/lib/python2.7/lib2to3/fixes (on Python 2.7.5ish), the fixers in lib2to3 itself that use touch_import are: fix_intern, fix_callable, fix_operator and fix_reduce. Of those, only fix_operator and fix_reduce are enabled by python-modernize. So if we changed our own uses of touch_import, we'd solve most of the problem, even though we wouldn't be solving it for a handful of cases in fix_operator (specifically importing collections.Sequence, collections.Mapping, or numbers.Number) and fix_reduce (importing functools.reduce), in the unusual situation that something that needs fixing is before another import. I think we can live with that.

[daira]

Huh, I can no longer reproduce this using the tests that reproduced it before (which are now on master). Bumping this out of the 0.4 release.