Fix recently added enum value type prediction#10057
Merged
Merged
Conversation
In python#9443, some code was added to predict the type of enum values where it is not explicitly when all enum members have the same type. However, it didn't consider that subclasses of Enum that have a custom __new__ implementation may use any type for the enum value (typically it would use only one of their parameters instead of a whole tuple that is specified in the definition of the member). Fix this by avoiding to guess the enum value type in classes that implement __new__. In addition, the added code was buggy in that it didn't only consider class attributes as enum members, but also instance attributes assigned to self.* in __init__. Fix this by ignoring implicit nodes when checking the enum members. Fixes python#10000.
hauntsaninja
approved these changes
Mar 2, 2021
hauntsaninja
left a comment
hauntsaninja
left a comment
Collaborator
There was a problem hiding this comment.
This looks great. Thank you for fixing this and following up! (And congratulations on the lucky #10000)
embray
added a commit
to embray/mypy
that referenced
this pull request
Oct 24, 2023
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.
hauntsaninja
pushed a commit
that referenced
this pull request
Jan 18, 2026
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
In #9443, some code was added to predict the type of enum values where it is not explicitly when all enum members have the same type.
However, it didn't consider that subclasses of Enum that have a custom
__new__implementation may use any type for the enum value (typically it would use only one of their parameters instead of a whole tuple that is specified in the definition of the member). Fix this by avoiding to guess the enum value type in classes that implement__new__.In addition, the added code was buggy in that it didn't only consider class attributes as enum members, but also instance attributes assigned to self.* in
__init__. Fix this by ignoring implicit nodes when checking the enum members.Fixes #10000.
Test Plan
Apart from manually testing the example from #10000, new unit tests are included for the changed behaviour that fail on master (when running
runtests.py) and pass with this fix applied. Unchanged behaviour is already tested by existing unit tests.