# Draft typing spec chapter for constructors

**URL:** <https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744>\
**Category:** Typing\
**Tags:** typing-spec\
**Created:** [March 28, 2024, 2:26pm UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744 "2024-03-28T14:26:56Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![erictraut](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erictraut/32/15190_2.png) [@erictraut](https://discuss.python.org/u/erictraut)\
**Post date:** [April 8, 2024, 3:54pm UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/21 "2024-04-08T15:54:34Z")

</div>

> [@Jelle](#):
>
> If the issue is in a library, users can provide stub files.

Creating type stubs for a library is a tall ask for 99% of pylance’s 12M+ users. I don’t think that’s an acceptable answer.

> [@Jelle](#):
>
> That is no different from the situation with any other unannotated function.

There is precedent for this. Type checkers treat unannotated class and function decorators as having no effect on the decorated function. That makes sense because it’s a reasonable (and correct) assumption the vast majority of the time. Treating unannotated decorators as though they return `Any` and asking users to “write your own stubs if you want this to work” would be a big step backward in terms of usability. I see the metaclass ` __call__ ` case as similar. If a library author is going to do something extremely nonstandard, let’s put the onus on them to provide a non-`Any` return type annotation.

---

<div class="post-metadata">

**Author:** ![rchen152](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rchen152/32/16955_2.png) [@rchen152](https://discuss.python.org/u/rchen152)\
**Post date:** [April 9, 2024, 5:11am UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/22 "2024-04-09T05:11:21Z")

</div>

I feel like my ideal behavior (for both ` __call__ ` and ` __new__ `) would look something like:

- no return type annotation: assume an instance of the class is returned
- if annotated to return anything other than an instance of the class (including Any): something special is being done, don’t evaluate subsequent constructor methods

I agree with Eric’s point that this isn’t the time to try to introduce a full-blown Unknown type, but what about specifically special-casing constructor methods to have an assumed return type annotation when they’re left unannotated?

---

<div class="post-metadata">

**Author:** ![erictraut](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erictraut/32/15190_2.png) [@erictraut](https://discuss.python.org/u/erictraut)\
**Post date:** [April 9, 2024, 5:42am UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/23 "2024-04-09T05:42:25Z")

</div>

Thanks @rchen152, I think your suggestion strikes a good balance. I’m OK with carving out that special case for ` __call__ ` and ` __new__ `.

@Jelle, what do you think?

---

<div class="post-metadata">

**Author:** ![Jelle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jelle/32/1049_2.png) [@Jelle](https://discuss.python.org/u/Jelle)\
**Post date:** [April 9, 2024, 9:23am UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/24 "2024-04-09T09:23:40Z")

</div>

I’m fine with special-casing just unannotated methods. That also aligns with pyright’s behavior with class decorators ([Pyright Playground](https://pyright-play.net/?pythonVersion=3.13&strict=true&code=GYJw9gtgBALgngBwJYDsDmUkQWEMoCCKcANFCAKYBuFAhgDYD68CFAUGwCYXBQCuKWihRgYtGBU6NuAYzAAKGfQDOASgBcbKNvIUYfECihLlHbryFxpFOYpXrCxVVAC0APkdxNO3fsPGVDgABASERMQkpWTA2JVplZSgADW8dBHjTNiDLazlY%2BgyoAE1U7XSEjkoaBmZECnkk1TYquiYWeqLVIA)).

---

<div class="post-metadata">

**Author:** ![erictraut](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erictraut/32/15190_2.png) [@erictraut](https://discuss.python.org/u/erictraut)\
**Post date:** [April 9, 2024, 4:34pm UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/25 "2024-04-09T16:34:06Z")

</div>

I’ve updated the proposed spec to incorporate @rchen152’s suggestion. Please review and add comments if you think it’s unclear or I missed any important points.

[Added draft chapter to typing spec for constructors. by erictraut · Pull Request #1667 · python/typing (github.com)](https://github.com/python/typing/pull/1667/commits/21f18a5a717f4ba545c8d48c370f4f7aaf0979f2)

---

<div class="post-metadata">

**Author:** ![erictraut](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erictraut/32/15190_2.png) [@erictraut](https://discuss.python.org/u/erictraut)\
**Post date:** [April 11, 2024, 12:43am UTC](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744/26 "2024-04-11T00:43:38Z")

</div>

The typing council has signed off on this change, and it has been incorporated into the typing spec.

Thanks to everyone who contributed to the discussion!

[Previous page](https://discuss.python.org/t/draft-typing-spec-chapter-for-constructors/49744.md?page=1)
