-
Notifications
You must be signed in to change notification settings - Fork 879
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
TRY004
auto-fix is too aggressive
#2158
Comments
Thanks for filing! Looks like we're not handling the What would you suggest as a better methodology for TRY004? Only flag if there are no other statements in the |
I would prefer if it didn't flag if there is a return (method to escape) between the start of the block and the error being raised. That would imply (to me) that the error is not being raised due to the type of something but for some other reason. |
That seems reasonable to me. |
In any case, I don't think this should be autofixed by default. |
Let me think on it! We're already working on a more granular API for enabling safe and unsafe fixes of varying degrees. You also have full control to disable fixes for any rule or class of rules like so: [tool.ruff]
unfixable = ["TRY004", "B"] |
The
TRY004
(TC004
in try.ceratops) is a bit too aggressive for me.It is indicating an error in:
This is not a
TypeError
as whatTRY004
is saying it should be, and I don't like the auto-fix trying to correct this. I think this is aValueError
asthis
does not contain the value I am looking for.Note that the above also does not follow the example presented in the try.ceratops docs, namely:
Should raise a
TypeError
instead (as it is not the correct type).It seems like
ruff
is doing more withTRY004
than checking for errors raised if the type is not what is expected. It seems to be also applying this to cases where a type check is performed and then an error is raised within that check, not if the check fails.The text was updated successfully, but these errors were encountered: