Replies: 4 comments
-
Thanks for starting a discussion! I definitely identify with this — I've gone out of my way to implement deferred import tooling as well but that comes with its own complications. I'm curious to hear from others :) |
Beta Was this translation helpful? Give feedback.
-
I agree that this would be useful. We did this in the past at Spring, to ensure that Tensorflow was always a late-import. My instinct is that this should be an entirely new rule in |
Beta Was this translation helpful? Give feedback.
-
Thank you for the suggestion! I decided to implement it as a new rule in |
Beta Was this translation helpful? Give feedback.
-
Would it make sense to have an allow-list in addition to the ban list? That way one could do something like:
My particular use case is to warn about expensive imports for Airflow DAGs where we know that we shouldn't import some packages. Except, there's a few exceptions to this which makes us then either having to list all packages under |
Beta Was this translation helpful? Give feedback.
-
Hello,
I use ruff on a library codebase that gets imported a lot, and we value import speed quite a bit. We have a list of expensive imports that we ban from being imported at module level, allowing them only inline. Currently, we enforce this using a custom Pylint checker, but we'd love to switch it to Ruff. Here's an example of what I mean.
I'd like to implement this as a Ruff rule -- first without autofix, and then maybe adding autofix down the line. However, I can think of a couple approaches and I'm not sure what the preferred one is. One way is extending
TID251
to support a new config option, e.g.:Another way would be creating a whole new rule for this. I don't know of any existing flake8 extensions or other rules that do this, so I guess it might be a
RUF
rule, thoughTID
or something could work too (even if it's not quite the same as the original!)Would love to hear your thoughts -- thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions