Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--future moves specified namespace before __future__ #1463

Closed
tobiasherp opened this issue Sep 4, 2020 · 4 comments · Fixed by hypothesis/viahtml#107 or wwade/jobrunner#63
Closed
Labels
documentation Improvements or additions to documentation idea_for_next_major_release question Further information is requested

Comments

@tobiasherp
Copy link

I like to have compatibility packages like six right below the __future__ imports; therefore I tried --future six to isort the following little example:

 from __future__ import print_function
 
 import six
 from AccessControl import Unauthorized
 from six.moves.urllib.parse import urlsplit, urlunsplit
 
 print('done!')

However, because of the --future option, the six imports are put above the __future__ imports, like so:

import six
from six.moves.urllib.parse import urlsplit, urlunsplit

from __future__ import print_function
from AccessControl import Unauthorized


print('done!')

This won't compile, of course.
Nothing is allowed above __future__ imports but comments and the module docstring (and empty lines, and other __future__ imports).

@timothycrosley
Copy link
Member

In case you haven't ran into it yet, the guide for how to accomplish custom grouping like this can be seen here: https://github.com/PyCQA/isort#custom-sections-and-ordering

@tobiasherp
Copy link
Author

Thank you; this helps in my case. I added the following lines to my configuration file:

known_compatibility=six,future
sections=FUTURE,COMPATIBILITY,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDER

This worked nicely.

However, with existing from __future__ imports, the --future option will yield invalid Python files.

@tobiasherp
Copy link
Author

Ok, I have a very nice configuration now, including custom grouping.
Seems I misunderstood the purpose of that --future option:

Force isort to recognize a module as part of the
future compatibility libraries.

But, if it is not compatible with __future__ imports - what is it needed for, then?
To me, it looks like it should feed a compatibility group instead (like in my configuration above), and perhaps get an additional (prefered) long option --compatiblity to make this clear.

@timothycrosley timothycrosley added documentation Improvements or additions to documentation idea_for_next_major_release question Further information is requested labels Sep 5, 2020
@timothycrosley
Copy link
Member

Right now --future is really just a naive but consistent exposure of the internal config options:

KNOWN_FUTURE, KNOWN_STDLIB, KNOWN_...

There are many ways to make it valid, such as forcing __future__ to top with --top combined with from_first, however it's certainly not ideal. I really Iike the idea of no longer exposing this internal and exposing a --compatibility or similar option in the future. Due to isort's release policy, this will need to wait for the next major release, however in the meantime I've updated the documentation with these notes to help guide other users to using the same kind of configuration that you created.

Thanks!

~Timothy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation idea_for_next_major_release question Further information is requested
Projects
None yet
2 participants