Skip to content
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

Allow is and is not for direct type comparisons #7905

Merged
merged 1 commit into from
Oct 20, 2023
Merged

Conversation

charliermarsh
Copy link
Member

@charliermarsh charliermarsh commented Oct 11, 2023

Summary

This PR updates our E721 implementation and semantics to match the updated pycodestyle logic, which I think is an improvement. Specifically, we now allow type(obj) is int for exact type comparisons, which were previously impossible. So now, we're largely just linting against code like type(obj) == int.

This change is gated to preview mode.

Closes #7904.

Test Plan

Updated the test fixture and ensured parity with latest Flake8.

@charliermarsh charliermarsh requested a review from zanieb October 11, 2023 00:33
{
if !matches!(op, CmpOp::Is | CmpOp::IsNot | CmpOp::Eq | CmpOp::NotEq) {
continue;
if is_type(left, checker.semantic()) || is_type(right, checker.semantic()) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlike pycodestyle, our rule is symmetric... so, e.g., we flag both type(x) == int and int == type(x).

Copy link

@CharString CharString Aug 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is is commutative, but == isn't in Python:

[ins] In [14]: (a == b) == (b == a)
Out[14]: False

[ins] In [15]: (a is b) == (b is a)
Out[15]: True

But I don't think that matters for this linter rule. :)

@github-actions
Copy link
Contributor

github-actions bot commented Oct 11, 2023

PR Check Results

Ecosystem

ℹ️ ecosystem check detected changes. (+3, -1, 0 error(s))

rotki (+3, -1)

- [*] 11 fixable with the `--fix` option (225 hidden fixes can be enabled with the `--unsafe-fixes` option).
+ [*] 13 fixable with the `--fix` option (225 hidden fixes can be enabled with the `--unsafe-fixes` option).
+ rotkehlchen/tests/api/test_settings.py:146:81: RUF100 [*] Unused `noqa` directive (unused: `E721`)
+ rotkehlchen/tests/api/test_settings.py:150:80: RUF100 [*] Unused `noqa` directive (unused: `E721`)

Rules changed: 1
Rule Changes Additions Removals
RUF100 2 2 0

Comment on lines -22 to 28
/// if type(obj) is type(1):
/// if type(obj) == type(1):
/// pass
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the "Use instead" section needs to contain the following:

if type(obj) is type(1):
	pass

Comment on lines 91 to 102
Expr::Attribute(ast::ExprAttribute { value, .. }) => {
// Ex) `type(obj) is types.NoneType`
if checker
.semantic()
.resolve_call_path(value.as_ref())
.is_some_and(|call_path| matches!(call_path.as_slice(), ["types", ..]))
{
checker
.diagnostics
.push(Diagnostic::new(TypeComparison, compare.range()));
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't present in the refactored code, is that an expected behavior?

The following doesn't get violated then:

if type(foo) == types.LambdaType:
    ...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, they removed this from pycodestyle with the understanding that a user-defined types would be a lot more common than accessing the standard library's types. I'm torn on it but figured it's fine to follow suit.

@charliermarsh
Copy link
Member Author

This may need to go out under preview \cc @zanieb

@charliermarsh
Copy link
Member Author

@zanieb - What do you think of this?

@zanieb
Copy link
Member

zanieb commented Oct 20, 2023

I agree preview makes sense for this change.

Perhaps we should clarify in the versioning policy that we will confine changes in the scope of rules to minor releases.

@charliermarsh charliermarsh force-pushed the charlie/E721 branch 4 times, most recently from 7fa0918 to dfcb2f7 Compare October 20, 2023 23:15
@charliermarsh charliermarsh added the rule Implementing or modifying a lint rule label Oct 20, 2023
@charliermarsh charliermarsh enabled auto-merge (squash) October 20, 2023 23:16
@charliermarsh charliermarsh merged commit df807ff into main Oct 20, 2023
15 checks passed
@charliermarsh charliermarsh deleted the charlie/E721 branch October 20, 2023 23:27
dhruvmanila pushed a commit that referenced this pull request Jun 25, 2024
…` (`E721`) (#11220)

## Summary

Stabilizes `E721` behavior implemented in #7905.

The functionality change in `E721` was implemented in #7905, released in
[v0.1.2](https://github.com/astral-sh/ruff/releases/tag/v0.1.2). And
seems functionally stable since #9676, without an explicit release but
would correspond to
[v0.2.0](https://github.com/astral-sh/ruff/releases/tag/v0.2.0). So the
deprecated functionally should be removable in the next minor release.

resolves: #6465
MichaReiser pushed a commit that referenced this pull request Jun 27, 2024
…` (`E721`) (#11220)

## Summary

Stabilizes `E721` behavior implemented in #7905.

The functionality change in `E721` was implemented in #7905, released in
[v0.1.2](https://github.com/astral-sh/ruff/releases/tag/v0.1.2). And
seems functionally stable since #9676, without an explicit release but
would correspond to
[v0.2.0](https://github.com/astral-sh/ruff/releases/tag/v0.2.0). So the
deprecated functionally should be removable in the next minor release.

resolves: #6465
MichaReiser pushed a commit that referenced this pull request Jun 27, 2024
…` (`E721`) (#11220)

## Summary

Stabilizes `E721` behavior implemented in #7905.

The functionality change in `E721` was implemented in #7905, released in
[v0.1.2](https://github.com/astral-sh/ruff/releases/tag/v0.1.2). And
seems functionally stable since #9676, without an explicit release but
would correspond to
[v0.2.0](https://github.com/astral-sh/ruff/releases/tag/v0.2.0). So the
deprecated functionally should be removable in the next minor release.

resolves: #6465
charliermarsh added a commit that referenced this pull request Jul 12, 2024
## Summary

I don't fully understand the purpose of this. In #7905, it was just
copied over from the previous non-preview implementation. But it means
that (e.g.) we don't treat `type(self.foo)` as a type -- which is wrong.

Closes #12290.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule Implementing or modifying a lint rule
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Does ruff have a plan for addressing flake8 or pycodestyle new changes?
4 participants