Repository navigation
Typing spec update for constructors #25
Description
I'd like to request that the TC consider adoption of a new chapter in the typing spec that spells out type checking behaviors related to constructor calls.
Links to PR & Discussion
The PR can be found here. The latest draft incorporates feedback from PR reviews and the discussion.
The discussion can be found here.
TC Sign-off
- Eric
- Guido
- Jelle
- Rebecca
- Shantanu
Current Type Checker Behaviors
None of the type checkers fully comply with the proposed behavior.
I haven't written a full test suite, but I created a partial suite to test current behaviors. Here are the results.
| Area | mypy | pyright | pyre | pytype |
|---|---|---|---|---|
Honors metaclass __call__ |
no | yes | yes | no |
__new__ basic specialization |
yes | yes | yes | partial |
Honors __new__ return type |
no | partial | no | no |
Skips __init__ based on __new__ return type |
no | yes | no | no |
Validates binding of __new__ cls |
no | partial | no | no |
__init__ basic specialization |
yes | yes | yes | partial |
Validates binding of __init__ self |
no | partial | no | no |
Honors __init__ self annotation (basic) |
partial | yes | yes | no |
Honors __init__ self annotation (func TypeVar) |
no | no | yes | no |
Rejects __init__ self annotation (class TypeVar) |
no | no | no | no |
| Constructor specialization defaults | partial | yes | no | no |
| Converting constructor to callable | partial | partial | partial | partial |
Controversial Issues
There is one potentially controversial issue related to the handling of a metaclass __call__ that has a return type (implicit or explicit) of Any or a union that includes Any. If you're interested in the details, refer to the discussion thread.
EDIT: We've resolved this issue through a compromise suggested by Rebecca. This is reflected in the latest draft.
Activity
gvanrossum commentedon Apr 10, 2024
I've signed off. Thanks for this, Eric!