Added draft chapter to typing spec for constructors. #1667
Conversation
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
docs/spec/constructors.rst
Outdated
| After evaluating the ``__new__`` method, a type checker should evaluate the | ||
| ``__init__`` method using the supplied arguments. If the class is |
There was a problem hiding this comment.
| After evaluating the ``__new__`` method, a type checker should evaluate the | |
| ``__init__`` method using the supplied arguments. If the class is | |
| After evaluating the ``__new__`` method (and the return type is unspecified), a type checker should evaluate the | |
| ``__init__`` method using the supplied arguments. If the class is |
Same as my other comment: as written in the __new__ section:
If the return type of the
__new__method is specified asAny(or the return type is unspecified and not inferred), a type checker should assume that the return type isSelf, and it should proceed to evaluate the__init__method.
…when a class doesn't inherit a `__new__` or `__init__` from a class other than `object`.
…hat returns `Any`. Also clarified what happens when a call to `__call__` or `__new__` evaluates to a union type.
…ethods to reflect suggestion from @rchen152 in [this post](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/22).
There was a problem hiding this comment.
This is an excellent piece of work. I'm approving it as-is -- I would have no objection if it went in unchanged -- but at the same time I have picked a bunch of nits and asked a few questions that you might consider to improve the readability of the spec slightly.
| def __new__(cls) -> Any: | ||
| return 0 | ||
|
|
||
| # The __init__ method will not be called in this case, so |
There was a problem hiding this comment.
Not sure I understand what you mean, but I rephrased the comment for clarity.
| As discussed above, if a class is generic and not explicitly specialized, its | ||
| type variables should be solved using the arguments passed to the ``__new__`` | ||
| and ``__init__`` methods. If one or more type variables are not solved during | ||
| these method evaluations, they should take on their default values. |
There was a problem hiding this comment.
I think this answers a question I had above. Maybe there could be a forward reference planted in the text there? (The text of the rules around specialization is rather long and I found it a bit hard to follow -- maybe this could be explained in depth here, leaving the earlier text shorter?)
|
Thanks! All good now. |
|
All members of the TC have signed off on this change, so I'm going to merge it. |
* Added draft chapter to typing spec for constructors. * Update docs/spec/constructors.rst Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> * Update docs/spec/constructors.rst Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> * Update docs/spec/constructors.rst Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> * Added section on signature consistency between `__new__` and `__init__`. * Incorporated PR feedback. * Added clarification based on question in forum. * Incorporated feedback about callable conversion. Clarified behaviors when a class doesn't inherit a `__new__` or `__init__` from a class other than `object`. * Tweaked the spec based on Jelle's feedback about a `__new__` method that returns `Any`. Also clarified what happens when a call to `__call__` or `__new__` evaluates to a union type. * Updated handling of `Any` return types for `__call__` and `__new__` methods to reflect suggestion from @rchen152 in [this post](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/22). * Incorporated feedback from @gvanrossum. --------- Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
DRAFT VERSION FOR REVIEW — DO NOT MERGE