-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
pyupgrade
rule: upgrading str, Enum
to StrEnum
#9569
Labels
Comments
Sounds good to me! |
zanieb
added
good first issue
Good for newcomers
rule
Implementing or modifying a lint rule
labels
Jan 17, 2024
Side note here: |
Hey @zanieb, is this issue active? Can I try to upgrade this? |
Go for it @arferreira! |
Relevant discussion: #3867 |
charliermarsh
pushed a commit
that referenced
this issue
Apr 6, 2024
## Summary Add new rule `pyupgrade - UP042` (I picked next available number). Closes #3867 Closes #9569 It should warn + provide a fix `class A(str, Enum)` -> `class A(StrEnum)` for py311+. ## Test Plan Added UP042.py test. ## Notes I did not find a way to call `remove_argument` 2 times consecutively, so the automatic fixing works only for classes that inherit exactly `str, Enum` (regardless of the order). I also plan to extend this rule to support IntEnum in next PR.
Glyphack
pushed a commit
to Glyphack/ruff
that referenced
this issue
Apr 12, 2024
…#10713) ## Summary Add new rule `pyupgrade - UP042` (I picked next available number). Closes astral-sh#3867 Closes astral-sh#9569 It should warn + provide a fix `class A(str, Enum)` -> `class A(StrEnum)` for py311+. ## Test Plan Added UP042.py test. ## Notes I did not find a way to call `remove_argument` 2 times consecutively, so the automatic fixing works only for classes that inherit exactly `str, Enum` (regardless of the order). I also plan to extend this rule to support IntEnum in next PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Since Python 3.11 there are now
StrEnum
andIntEnum
:pyupgrade
can be used to suggest this change.However, this request was rejected in
pyupgrade
itself here: asottile/pyupgrade#779. Apparently they're not identical in behavior. Luckily,ruff
has a concept of safe vs unsafe, so I thinkruff
can actually implement this rule.The request here is for
ruff
to suggest this upgrade as an unsafe fix, ideally with autofix support.The text was updated successfully, but these errors were encountered: