Type enum.auto according to implementation

[srittau]

Exploratory PR.

Cf. #8286

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[srittau]

3.11-dev seems to have switch Python versions. I'll make a separate PR addressing those issues.

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[github-actions[bot]]

Diff from mypy_primer, showing the effect of this PR on open source code:

kopf (https://github.com/nolar/kopf)
+ kopf/_cogs/structs/diffs.py:28: error: Unsupported left operand type for | ("auto")

[srittau]

I thought that mypy supports __new__(), but that doesn't seem to be the case:

class X:
    def __new__(cls) -> int:  #  type: ignore[misc]
        return 43

reveal_type(X())  # Revealed type is "foo.X"
print(type(X()))  # <class 'int'>

[AlexWaygood]

I thought that mypy supports __new__(), but that doesn't seem to be the case:

class X:
    def __new__(cls) -> int:  #  type: ignore[misc]
        return 43

reveal_type(X())  # Revealed type is "foo.X"
print(type(X()))  # <class 'int'>

I think it only supports __new__ if the __new__ method returns a type that's a subtype of cls 😕 otherwise, it simply views it as an invalid __new__ method and ignores it. Not sure what pyright's stance on this kind of thing is.

We're never going to be able to fully express what happens at runtime here; it's too magical. It needs to be special-cased by the type checker.

What if, instead of subclassing IntFlag, we subclassed Any? That should get rid of the false-positive errors, and also hopefully fix the Pycharm issue.

[srittau]

Subclassing Any has the disadvantage of losing all type checking. I'll try another approach first.

[github-actions[bot]]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[github-actions[bot]]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[github-actions[bot]]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[github-actions[bot]]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉