Closed jparise closed 6 years ago
I'm not sure about this, given that none of the current styles specify a priority grouping. I'm also unsure as I think these is a rare use-case that actually might suit #noqa
better. It may make more sense to restore # noqa
on import gevent
having an affect. Do you see any other use cases?
This is orthogonal to styles (akin to the __future__
prioritization), but regardless, I'm also in favor of the # noqa
approach. Do you have a sense for what it would take to make that work for these cases?
Don't both those examples show a situation in which you'd want to import a module first in one of the modules in the package likely followed by normally in the other modules? For example I'd likely want to do,
# init.py
import eventlet
eventlet.monkey_patch_all()
import os
# other.py
import os
from eventlet import spawn
I'm still struggling to see the use case whereby you'd want a priority in every file.
I think you're right. In my gevent example, there's a distinct gevent.monkey
module that is used for all monkey patching, but your eventlet example shows that's not the rule.
Let's pursue the # noqa
approach (#136) instead.
You can set the
priority-import-names
option to a comma separated list of names that will be considered "priority" imports. These names are allowed to appear before the standard library grouping, making it easier to apply custom behavior (e.g. monkey patches) to subsequent import statements.For example:
There doesn't appear to be another way to support this pattern. The error would appear on the
import socket
line above, and that's not the correct place to add a#noqa
annotation.I don't love the name "priority" for this. I also considered "early", but that's equally ambiguous. I'm more than happy to rename this to something else.