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

type-comparison (E721) only works on some builtin classes and nothing else #6465

Closed
DetachHead opened this issue Aug 10, 2023 · 12 comments · Fixed by #11220
Closed

type-comparison (E721) only works on some builtin classes and nothing else #6465

DetachHead opened this issue Aug 10, 2023 · 12 comments · Fixed by #11220
Assignees
Labels
rule Implementing or modifying a lint rule
Milestone

Comments

@DetachHead
Copy link

def asdf(value: object):
    type(value) is str  # error
    type(value) is int  # error
    type(value) is list  # no error
    type(value) is dict  # no error

    class Foo:
        ...

    type(value) is Foo  # no error

pylint's unidiomatic-typecheck detects all of these cases

@charliermarsh
Copy link
Member

I'm honestly tempted to revert the changes to this rule and just go back to pycodestyle parity, because I don't really understand the contexts in which pycodestyle is meant to be enforcing it, and it doesn't seem worth it to me to keep spending time refining it. (This rule in pycodestyle is not the same as unidiomatic-typecheck, and we're now deviating from both subtly.)

For example, pycodestyle allows type(a1) is type(b1), type(a1) is int, etc., but disallows type(a) is type(1). I don't really understand it.

Separately, comparing type(value) is int is actually reasonable to me in some cases if you want to do a direct comparison, not a subclass comparison. I assume that's why pycodestyle is more limited in its rule.

@charliermarsh charliermarsh added the needs-decision Awaiting a decision from a maintainer label Aug 10, 2023
@charliermarsh
Copy link
Member

(I added the missing builtin types at least.)

@bdowning
Copy link

bdowning commented Jan 8, 2024

IMHO ruff needs to allow stuff like type(foo) is int. flake8 allowed this, it just disallowed type(foo) == int and recommended replacing == with is and not replacing with isinstance, which obviously has completely different behavior. I just had code break from "fixing" lint violations with isinstance due to a behavior change (because bool is a subclass of int for some insane reason).

@charliermarsh
Copy link
Member

@bdowning -- I believe we already allowed that if you run with --preview: https://play.ruff.rs/90c3ddba-0c1f-450d-96bc-df09ee8e6adb. (This will become stable behavior when we ship v0.2.0.)

@bdowning
Copy link

bdowning commented Jan 9, 2024

Thanks. BTW, the playground seems more than a little busted on Firefox right now:
image

@bdowning
Copy link

bdowning commented Feb 2, 2024

@charliermarsh So I updated to 0.2.0 and I'm still only seeing stuff like type(foo) is int being allowed with --preview. Did this not make the cut?

$ poetry run ruff --version
ruff 0.2.0
$ poetry run ruff xxx/
warning: The top-level linter settings are deprecated in favour of their counterparts in the `lint` section. Please update the following options in `pyproject.toml`:
  - 'ignore' -> 'lint.ignore'
  - 'select' -> 'lint.select'
  - 'isort' -> 'lint.isort'
xxx/yyy.py:193:8: E721 Do not compare types, use `isinstance()`
xxx/yyy.py:195:10: E721 Do not compare types, use `isinstance()`
xxx/yyy.py:199:10: E721 Do not compare types, use `isinstance()`
Found 3 errors.
$ poetry run ruff --preview xxx/
warning: The top-level linter settings are deprecated in favour of their counterparts in the `lint` section. Please update the following options in `pyproject.toml`:
  - 'ignore' -> 'lint.ignore'
  - 'select' -> 'lint.select'
  - 'isort' -> 'lint.isort'
$

@zanieb
Copy link
Member

zanieb commented Feb 2, 2024

It's possible we missed this in the 0.2.0 stabilizations. For what it's worth, I think this is a bug and we should fix it immediately.

@zanieb zanieb self-assigned this Feb 2, 2024
@bdowning
Copy link

bdowning commented Apr 6, 2024

@zanieb Any word on this? Just checked with 0.3.5 and it looks like this is still behind the preview barrier.

@joaoe
Copy link

joaoe commented Jun 7, 2024

Hi.
I'm hitting this warning.

Now and then I want to do type(a) is B or type(a) is type(c) to do strict type checking, not subclassing, namely in unit tests.

The type(...) is ... check with the is operator should be allowed and not trigger a warning, or in an alternative case, produce a separate warning from E721 which we can choose to ignore.
Cheers.

@dhruvmanila
Copy link
Member

@joaoe Can you try your example with --preview mode? This is resolved in preview mode, we just need to move it into stable in the next minor release.

@dhruvmanila dhruvmanila added rule Implementing or modifying a lint rule and removed needs-decision Awaiting a decision from a maintainer labels Jun 12, 2024
@dhruvmanila dhruvmanila added this to the v0.5.0 milestone Jun 12, 2024
@dhruvmanila
Copy link
Member

Ok, there's a PR up which will resolve this: #11220

dhruvmanila pushed a commit that referenced this issue 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
@dhruvmanila
Copy link
Member

The preview logic has been moved to stable and will be released as part of v0.5.

Resolved by #11220

@MichaReiser MichaReiser mentioned this issue Jun 26, 2024
MichaReiser pushed a commit that referenced this issue 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 issue 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
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 a pull request may close this issue.

6 participants