I like the syntax proposed by PEP 695, and I hope we end up with something like it eventually. But, I also support delaying it until at least 3.13.
I know there’s been a lot of incredible work done recently to try to get the implementation ready in time for 3.12, and I really appreciate that work. However, the PEP is a huge change that deserves to be well tested. Testing the PEP with real code – rather than in isolated unit tests – could possibly reveal flaws in the design that would require rewrites of the initial implementation. I don’t think we should go through that process during the 3.12 beta phase.
Moreover, while I support us reaching this kind of syntax eventually, I also care a lot about the stability of Python’s syntax and Python’s typing system. It was recently indicated to some core developers that the Steering Council was planning not to make a decision on PEP 696 for now, because they preferred to see how PEP 695 played out first. I strongly believe that this is the wrong order in which to do things. PEP 696 does not require any syntax changes to the language if it is implemented before PEP 695. But if PEP 695 is implemented in Python 3.12, and PEP 696 is implemented in Python 3.13, we will need TypeVar-related syntax changes in two consecutive versions of Python. I think this will be really harmful to the stability of the language’s syntax and Python’s typing system.
I have previously expressed concerns that Python’s typing system was not stable enough to consider “freezing” the status quo in new syntax; that implementing PEP 695 now would make it harder to propose new typing features relating to TypeVars; and that the syntax changes proposed by PEP 695 would not be extensible without introducing further syntax changes:
- PEP 695: Type Parameter Syntax by erictraut · Pull Request #2697 · python/peps · GitHub
- PEP 695: Type Parameter Syntax - #22 by AlexWaygood
I feel like these concerns have been brushed aside a little bit, and that the current situation (where PEP 696 is being deferred at least in part because of PEP 695) is exactly the situation I was worried about. There has also been a recent proposal for a TypeVarDict
: it is unclear how that would interact with PEP 695, and whether accepting that idea would require yet more syntax changes if PEP 695 is implemented.
There are really three distinct ideas in PEP 695, and I wish it had been split into three PEPs:
- Allowing type checkers to infer the variance of
TypeVar
s rather than forcing users to manually specify it when defining aTypeVar
- New syntax for declaring type aliases
- New syntax for declaring generic classes and functions
Idea (1) in the PEP would be a huge usability improvement to the type system and, if implemented on its own, would not require any changes to Python’s syntax. The infer_variance
keyword argument (which is all this idea needs to be implemented, if it is isolated from the other two ideas in the PEP) has already been backported to typing_extensions.TypeVar
. I would feel much happier if we implemented only idea (1) for Python 3.12, and took some more time to further consider and work on implementing the two other parts of the PEP.