Prevent from * import * to be splitted

[adhikasp]

This will prevent a from something import a, b, c to be splitted.

Test code

from math import sqrt, log, tan, cos
import os, sys, collections

print(log(2))
print(tan(5))
print(os)
print(sys)

Result

--- original/tes.py
+++ fixed/tes.py
@@ -1,5 +1,6 @@
-from math import sqrt, log, tan, cos
-import os, sys, collections
+from math import log, tan
+import os
+import sys

 print(log(2))
 print(tan(5))

Closes #7

[coveralls]

Coverage increased (+0.07%) to 98.577% when pulling fa06eb7 on adhikasp:no-split-from-import into 1ff40b8 on myint:master.

[myint]

Cool! I'll take a closer look later this week.

[myint]

I committed a relevant test case in 71fa850. Could you try that?

Also, could you add the following test case?

from frommer import abc, frommer, xyz

Currently, with this pull requests, I get the following error from the above.

$ ./autoflake.py foo.py
Traceback (most recent call last):
  File "./autoflake.py", line 595, in <module>
    sys.exit(main())
  File "./autoflake.py", line 589, in main
    standard_error=sys.stderr)
  File "./autoflake.py", line 572, in _main
    fix_file(name, args=args, standard_out=standard_out)
  File "./autoflake.py", line 462, in fix_file
    remove_unused_variables=args.remove_unused_variables)
  File "./autoflake.py", line 441, in fix_code
    remove_unused_variables=remove_unused_variables))))
TypeError: sequence item 0: expected str instance, NoneType found

Thanks

[adhikasp]

Ok will do it 👍

[adhikasp]

Updated:

• More robust regex to only call the new function (filter_from_import()) if from is on the start of line.
• The bug you post is because filter_from_import() remove the file content on first pass (hence the next iteration in fix_code got None, not a string).
  I fix this by return pass in case of from something import unused1, unused2 and rely on removing useless pass routine to clean up.
• Additional test cases

[coveralls]

Coverage increased (+0.08%) to 98.592% when pulling 6ac31f1 on adhikasp:no-split-from-import into 71fa850 on myint:master.

[myint]

How about:

from collections import defaultdict, namedtuple as xyz

It seems to currently give:

$ ./autoflake.py foo.py
--- original/foo.py
+++ fixed/foo.py
@@ -1 +1 @@
-from collections import defaultdict, namedtuple as xyz
+from collections import as, namedtuple, xyz

[adhikasp]

from ... import ... as handled correctly.

One thing that still buggy is if the input have irregular spacing (more than 1) will not removed because i directly compare them with output from pyflakes.

from a import b   as   c 

Do you think we should handle that too?

[coveralls]

Coverage increased (+0.09%) to 98.625% when pulling 885a427 on adhikasp:no-split-from-import into 3f71764 on myint:master.

[myint]

Great work!

I think leaving irregular spacing untouched is fine.

I have one thing I want to confirm. Is this new feature meant for top-level imports only? I noticed:

--- original/foo.py
+++ fixed/foo.py
@@ -1,3 +1,4 @@
 def z():
-    from ctypes import c_short, c_uint, c_int, c_long, pointer, POINTER, byref
+    from ctypes import POINTER
+    from ctypes import byref
     POINTER, byref

It seems to use the old behavior for indented cases. This is fine if intended. But I just wanted to check.

Thanks

[adhikasp]

Oh no, I did not mean that. The behaviour of top-level import and inside function should be same right?

I made change to support non-top level import and the related test.

[coveralls]

Coverage increased (+0.09%) to 98.653% when pulling 23dd99f on adhikasp:no-split-from-import into 5a00d0d on myint:master.

[myint]

Thanks for sticking with this! I'm running fuzz tests against this right now. Once it runs okay for a bit longer, I'll merge it.

[coveralls]

Coverage increased (+0.1%) to 98.667% when pulling ce723cb on adhikasp:no-split-from-import into 5a00d0d on myint:master.

[coveralls]

Coverage increased (+0.1%) to 98.667% when pulling 5763dde on adhikasp:no-split-from-import into 5a00d0d on myint:master.

[myint]

Interesting! Somehow I committed to your repository. I was intending to continue committing to my branch. But instead, my latest commits ended up in your repository's branch of the same name. Maybe GitHub grants permission to the repository owner to modify pull request branches from the repository fork.