-
Notifications
You must be signed in to change notification settings - Fork 750
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
E721 regression(s) #1084
Comments
I'm going to revert the change for now to unblock the release -- and we can reconsider that later given the above. I think probably the most practical thing is to change the error message to suggest |
I put up my proposal above as #1086 |
Will this PR also fix this scenario?:
I want to test if a value is exactly an int, not any type that inherits from it. Otherwise I can raise a separate issue. |
@jepperaskdk just try it |
With pycodestyle 2.11, comparing types with `is` is no longer an error: PyCQA/pycodestyle#1084
* pyproject.toml: Upgrade flake8 and pycodestyle for Python 3.12 * Update poetry.lock * config: Move inline comments to separate lines for compatibility with flake8 >=6.0 * Coding-Conventions.md: Update E721 example With pycodestyle 2.11, comparing types with `is` is no longer an error: PyCQA/pycodestyle#1084 * tests: Update structural_tests to pass with pycodestyle 2.9 and 2.11 pycodestyle 2.11 no longer reports E741 - ambiguous variable name for `if l == True` because it doesn't contain an assignment. PyCQA/pycodestyle#1118 * PR workflow: Test with Python 3.12
so #1041 brought up a lot more instances of E721 and I don't feel confident adding this in a release since it's going to cause a bunch of (imo) unnecessary work
for example, here's something which wasn't flagged before but is now:
strictly speaking the lint rule probably should match this, but almost every case I can find with
is
andis not
is being very explicit about the types being checkedI think the most reasonable thing to do here is to only check
==
and!=
-- those are the ones that are most likely actual mistakes rather than an explicit check.the other option is revert #1041 -- which might be the quickest thing to do to not block a release -- unclear what the best approach is here
The text was updated successfully, but these errors were encountered: