[ty] Support custom __new__ in enums for value type inference#23448
Draft
rayzeller wants to merge 2 commits intoastral-sh:mainfrom
Draft
[ty] Support custom __new__ in enums for value type inference#23448rayzeller wants to merge 2 commits intoastral-sh:mainfrom
__new__ in enums for value type inference#23448rayzeller wants to merge 2 commits intoastral-sh:mainfrom
Conversation
When an enum defines a custom `__new__`, the raw assignment type doesn't represent the member's value — `__new__` unpacks arguments and explicitly sets `_value_`. Fall back to the `_value_` annotation type if declared, or `Any` otherwise. Closes: astral-sh/ty#876 (partial — "Custom `__new__` or `__init__` methods in enums") Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Typing conformance resultsNo changes detected ✅ |
Memory usage reportMemory usage unchanged ✅ |
|
rayzeller
force-pushed
the
ty-enum-custom-new
branch
from
5d8ae02 to
7618cdc
Compare
…new` Remove the `_value_` annotation lookup logic to avoid overlap with astral-sh#22228, which handles `_value_` semantics more broadly. Custom `__new__` enums now always fall back to `Any`. Also remove the redundant known-class skip list from `has_custom_enum_new` — the vendored path check already covers all stdlib classes. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
rayzeller
force-pushed
the
ty-enum-custom-new
branch
from
7618cdc to
ab0238a
Compare
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.
Summary
Enums with a custom
__new__unpack their assigned values as arguments and explicitly set_value_inside the method body. Previously, ty inferred the raw assignment type as the member's value (e.g.tuple[float, float]instead offloat), producing incorrect.valuetypes.This PR follows pyright's pragmatic approach: when a custom
__new__is detected, don't analyze its body — instead fall back toAny.Example
What changed
has_custom_enum_new()— walks the MRO to detect custom__new__, skipping known stdlib classes and stub-file definitions (e.g.IntEnum.__new__,IntFlag.__new__)enum_metadata()to override member value types withAnywhen custom__new__is presentWhat's unaffected
__init__without__new__— value inference unchanged.nameaccess, member detection — all still workIntEnum,StrEnum, standard enums — no behavior changePartial fix for astral-sh/ty#876
Test plan
New mdtest section in
enums.mdwith 6 test cases: custom__new__with tuple values,__init__-only regression, inherited__new__via MRO, standard enum regression,IntEnumnot affected, member detection, and exhaustiveness.🤖 Generated with Claude Code