Proposed new typing governance process

I think that might be what we call the “1.0” testsuite.

The initial version should be very much smaller for a number of reasons, most importantly “inertia and startup cost”. But also we may find that the structure of the tests needs to change to accommodate everyone’s needs, and such adjustments will be much easier while the suite is small.

I have some past exposure to this kind of cross-implementation testsuite via JSON Schema, and it works extremely well for them. Their spec is explicitly versioned, and there are other differences, but there may be useful takeaways from their prior art. Notably, new spec versions are written with test cases as part of the process, and it’s a great way both for implementations to validate and for the spec authors to get some confirmation back from the implementers.

1 Like

Overall concept sounds like a good idea to me, but I see a potential middle ground between “only initially specify a subset” and “bulk copy & paste from the PEP specification sections”: adopt the approach of building out a self-consistent specification from an initial core, but include a stub section with relevant PEP references for every topic not yet covered in clarified prose (this approach could be used for both the implementor facing formal spec and the user facing docs).

Expanding on each such section might start with a PR based on the text in the relevant PEPs, but could be tidied up and better integrated with the rest of the text in the initial PR review.


As someone looking to learn all the caveats of python’s type system, and as someone who has been burned enough times by a piece of code being an error in one type checker but passing in another type checker, I am really excited about the conformance suite. It’ll make it really easy for people to find outlier examples and contribute to the type checkers.

If possible, can this test suite have a surplus of comments explaining test cases and their rationales? That would be an amazing resource.


Nothing more than a big :heavy_plus_sign: :one:, but -

As someone who leans on the type system (and a maintainer of libraries with a heavy reliance on it) and with what feels like a great increase in the usage of typing throughout the community, the idea of having streamlined specifications and consistent, intuitive usability is exciting.

Also (hopefully) with the added benefit of fostering collaboration and broader adoption of utilizing types among the Python dev community.

I think that’s a grand idea!

I wonder, has the SC made a clear roadmap of the typing property of the language. Fore now it’s optional and mostly at development time only. But is there an objective to make this more than that in the future? What’s the vision behind types in Python on the long run? Would the TC take that under its remit?

Quoting from the original typing PEP, PEP 484:

It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.

Python is frequently used in situations† where it would be burdensome to mandate the use of type annotations, so I don’t ever see them becoming required. (Of course individual projects can require them by configuring a typechecker with disallow_untyped_defs or a similar option.)

Python type annotation objects (“type forms”) have already seen successful uses at runtime (rather than at development time), probably most notably in FastAPI and Pydantic. I expect continued uses of type annotations at runtime.

† small & medium-sized programs; education; scripts; programs written by infrequent Python users

There’s a separate (long) thread talking about long-term typing vision.


Thanks for the links.

As for the PEP 484 quote, I’d say it is only fair the question is asked again. PEP 484 is almost ten years old.

I would say that the prominent use of type annotations in everything from the standard library (dataclasses) to IDEs which provide autocomplete using them, to third party libraries that can do things as expressive as automatically build appropriate HTTP routes from typed user functions says that the ship has sailed on them being optional socially.

That feels like misleading rhetoric. You might as well state that the ship has sailed on metaclasses. We can’t deny their existence – every class has a metaclass, which you can introspect – but most users never or rarely need to know anything about them.

Just because type annotations are required by dataclasses doesn’t mean they are no longer optional in other contexts – in particular, in their original contexts of function signatures, they are still very much optional (they get only 2-3 paragraphs in a faraway part of the official tutorial, for example). And as I’m sure you’re well aware the dataclasses stdlib module doesn’t actually care what you write for the annotation.

So I’d say that the answer hasn’t substantially changed since PEP 484 first appeared on the scene. It is easy to learn Python without learning about annotations (in fact most Python introductions use them barely or not at all). You can lead a happy and productive life writing Python code without knowing anything about type annotations. There are no plans to make them mandatory, nor are there plans to use them to enhance performance (in fact, none of the current performance efforts inside and outside of CPython that I am aware of use them at all).


There’s a reason I included the word “socially”. It’s very clear that the interpreter doesn’t need them, and the standard lib features don’t need them. The ecosystem as a whole is broadly using them though, and ignoring the social impacts of this on whether or not they are actually optional probably feeds into the things mentioned in the other thread, the drawbacks mentioned in the typing.Doc thread and so on.

1 Like

But the question earlier in this thread didn’t ask if it was still “socially optional”. That’s a term you just made up so you could answer “no, it isn’t optiional any more.” But the original question was this:

To which the answer is that it’s still optional and there are no plans or designs (except, perhaps, yours?) to change that. The TC is being created so that those people who do want to use (or evolve!) typing are better served – not to change or promote the position of typing in the language in general.

Also, a personal note – your style of arguing relentlessly makes me feel exasperated, and it is beginning to feel very repetitive. You appear to be in a small minority with an extreme position about typing. Could you perhaps let go of that and stop repeating your point of view so frequently? Clearly you cannot believe that we don’t hear you. We just disagree. It would be more useful if you started helping out in other ways than telling us what you think we should do.


I have no intent to change typing being optional. I think that acknowledging the social impact of various tooling using typing is important to ensure that typing is designed in a way that even those who are only tangentially exposed to typing through tooling and not through an intent to fully type their code have a good experience with it and that by your definition here, probably should be included in the discussion.

You seem to have misunderstood my view of typing. I have no intent to make it mandatory or require more from end users. I would prefer if it was possible to express more, and that the capabilities for it to do so were considered in a way that helps users from all camps without adverse effects on those who do not want to use it.

I’m sorry to hear that advocating for a better experience where applicable is being felt as exasperating, as for it being repetitive, it happens to be relevant to multiple ongoing discussions right now, and I’m not sure how else I can ensure that point is being considered in the discussion when you’re explicitly saying here that it’s not relevant because the question didn’t ask about social impact, and that it could not somehow be relevant to address that in addition.

1 Like

I find it disheartening that this is how someone so involved in python chose to assume this. Earlier in the thread, one of the responses brought up that the original wording included “optional by convention”

A user provided a quote from pep484:

And the response to that from the OP:

being “socially optional” as @mikeshardmind put it is not some made up concept, and I certainly didn’t read it as answering that typing was no longer optional. You claimed “misleading rhetoric” of another contributor here, but are assuming a lot that wasn’t said here. Can we ask people to clarify what they mean if it isn’t clear instead of assuming more from things they didn’t say?

I have a direct question to @Jelle as the author of the PEP proposing a typing council related to this:

If typing is becoming used by more people than it’s original audience because python and typing is introspectible, should the typing council need to consider the impacts of the design of typing on these users? If not, is this being considered during decision making? Also if not, is this the sole responsibility of libraries to only use typing introspection when it is easy for their users, and who should libraries raise issues in this space to if not the typing council?

Yes, I think it’s important that runtime use cases are considered. The draft PEP that expands on this proposal explicitly lists runtime type checking among use cases the Council should consider (PEP 729 – Typing governance process |

For me personally, this is important because I maintain a type checker (GitHub - quora/pyanalyze: A Python type checker) that relies on runtime introspection (though it is not primarily a runtime type checker). Therefore, I pushed for several changes to typing that improve runtime introspectability, such as adding ParamSpecArgs/Kwargs (previously those would just have been object()), making the @final decorator set the __final__ attribute, and adding typing.get_overloads.


My reading of that found contradicting points, which is why I asked.

On the other hand, Python 3.11 also added the typing.get_overloads() introspection helper. As this function does not affect type checker behavior, it would not require approval by the Typing Council.

This seems to limit the Typing Council to only things which effect type checking, not other uses of typing annotations runtime or otherwise, could this wording be amended to state to what extent the Typing Council would need to be considered here?


Thanks for clarifying. This is helpful because I often read engineers not considering Python as a “proper” production language for larger projects because it lacks support for typing as a core feature. I guess these comments come from folks used to static languages and therefore with a bias. But it felt like, as the story for typing keeps evolving, it was only natural to revisit that question of vision. To me, it’s fine either way.

I’m assuming here that I’m not the one targetted by this assertion. Discuss isn’t very good with threading comments. Either way, I had no intention in kicking a can of worms.

Sorry, the “you” in my post was Michael H.

1 Like

That’s a good point. My intent is that the core devs continue to make decisions over such changes to, because I don’t see a reason to change the status quo there, but the Typing Council should also consider these use cases and provide feedback if necessary. I pushed a change to the PEP draft to reflect that:

This is now PEP 729; discussion should move to PEP 729: Typing governance process.

1 Like