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

Fix enum value inference with user-defined data type mixin #16320

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

embray
Copy link

@embray embray commented Oct 24, 2023

Fixes enum value inference in cases where the value type is of a user-defined data type class (with __new__).

According to https://docs.python.org/3/howto/enum.html#others when defining an Enum subclass with a custom data type:

A data type is a mixin that defines __new__(), or a dataclass

This fixes a regression introduced by #10057 to fix #10000. The not ti.fullname.startswith("builtins.") clause seemed to be intended to catch enums with a built-in data type like int or bytes, but this is overly broad. It should allow any type so long as it is not itself an enum.Enum subclass.

embray and others added 2 commits October 24, 2023 12:21
user-defined data type class (with __new__).

This fixes a regression introduced by python#10057 to fix python#10000.  The
`not ti.fullname.startswith("builtins.") clause seemed to be intended
to catch enums with a built-in data type like int or bytes, but this is
overly broad.  It should allow any type so long as it is not itself an
enum.Enum subclass.
@github-actions
Copy link
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong enum value type inferred for members defined in a subclass (regression)
1 participant