-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
MNT: Enforce ruff/isort rules (I) #28969
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
Conversation
I001 Import block is un-sorted or un-formatted
Not needed after applying isort.
_NBitSingle as _NBitSingle, | ||
_NBitDouble as _NBitDouble, | ||
_NBitLongDouble as _NBitLongDouble, | ||
from ._array_like import ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious about the logic for this reformatting. Why the separation and parenthesis? It doesn't seem to apply when the names aren't prefixed with _
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems it is reserved for things like argh as argh
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jorenham Could you explain again why doing import x as x
is useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See unused-import (F401):
If an import statement is used to re-export a symbol as part of a module's public interface, consider using a "redundant" import alias, which instructs Ruff (and other tools) to respect the re-export, and avoid marking it as unused, as in:
from module import member as memberAlternatively, you can use
__all__
to declare a symbol as part of the module's interface, as in:# __init__.py import some_module __all__ = ["some_module"]
I am not opposed to just putting this in, one and done. I note that @jorenham tends to undo the import list expansions :) |
If needed, I am happy to apply non-default options for the |
I'd start with the defaults before going down that rabbit hole, a later update will likely be smaller. I do wonder if import order can have an impact. |
Thanks @DimitriPapadopoulos . |
Only in case of |
Changes are extensive. Should I split into multiple PRs? Use a more incremental approach (but how)?