# Proposed initial typing spec

**URL:** <https://discuss.python.org/t/proposed-initial-typing-spec/39389>\
**Category:** Typing\
**Tags:** typing-spec\
**Created:** [November 23, 2023, 2:58am UTC](https://discuss.python.org/t/proposed-initial-typing-spec/39389 "2023-11-23T02:58:25Z")\
**Posts on this page:** 1\
**Showing post:** 4

<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:** [November 23, 2023, 3:30pm UTC](https://discuss.python.org/t/proposed-initial-typing-spec/39389/4 "2023-11-23T15:30:55Z")

</div>

Thanks for the feedback!

> [@Daverball](#):
>
> I have noticed that the examples sometimes use features/constructs that have not yet been introduced at this point in the specification and sometimes even use them in ways that are discouraged/less common. Generally I think the examples should try to follow best practices and change as they evolve.

I agree that the examples should use best practices; I already made a lot of changes like `List` → `list`. I noticed in the section you linked (about type aliases) that I missed some `Type[T]` instances, so those still need to be fixed.

I don’t know if it’s worth to avoid using concepts in examples that have not yet been used. It seems difficult to do in all cases, and the audience for the spec should have a general familiarity with typing concepts already. The user-facing documentation is a separate project and need not follow the same structure.

> [@Daverball](#):
>
> Would you want us to report nit-picky issues like that or is that something that should be left for later?
> 
> I’ve also noticed that the formatting of examples is somewhat inconsistent, maybe we could leverage black to auto-format the examples?

Yes, feel free to report these. Note that the spec will be moved to a different repo (python/typing) eventually, so any CI setup would also need to be transferred later.

> [@sirosen](#):
>
> In many cases, the PEPs could be refined to match minor improvements. I think this process will support doing that in a mindful way.  
> Idea: label issues with the PEP numbers for easy categorization when/if folks want to backport improvements.

PEPs are meant to be historical documents that shouldn’t change after they’re implemented. This process is meant to reduce the reliance on old PEPs in the typing community. The PEPs we incorporate should get a banner pointing to the typing spec as the up-to-date canonical documentation.

> [@sirosen](#):
>
> I’m not sure where the best page breaks are offhand (“TypeVar and related constructs” seems like a logical page?), but I think a small number of pretty big pages would be a way to start.

I feel the logical choice is to make each of the top-level sections its own page. However, “Type system features” might need further splitting.

---

_[View the full topic](https://discuss.python.org/t/proposed-initial-typing-spec/39389)._