On Wed, 14 Apr 2021 at 08:21, Barry Warsaw <barry@python.org> wrote:
I wouldn’t necessarily be opposed to bundling a type checker with the interpreter/stdlib, but I think there are some issues with it. Just off the top of my head (there are undoubtedly many more issues to resolve):
* Which type checker would we adopt or adapt, if any?
Mypy. This has become an implementation issue, not one of which type system to adopt. A lot of code, even in the stdlib, has been annotated but I'm not aware of multiple different annotations with different semantics or type systems being created. For example, type equivalence by name only is used in Ada (or was, it's been many years) and probably other languages. In equivalence by name, the following code would not pass the type checker. x : list[int] y : list[int] x = y # Type error But I'm not aware of anyone implementing type by name equivalence for Python, and the original PEP 483 seems to explicitly close off that possibility. Instead the assumption seems to be Java/C++ structural equivalence for types. Skimming a bunch of current type system related PEPs, I'm not seeing anything that a Java/C++ programmer would find unfamiliar. And this is probably a good thing.
* Which parts of the typing system require more frequent release cycles? * Is there a core technology that could be put in the stdlib and still allow experimentation? * Would the type checker authors become core developers? * Do the same feature release / deprecation policies apply?
No answers from me.
I would still be opposed to requiring type hinting in Python.
I'm opposed to requiring type hints on everything, I want to still be able to write x = 1 x = "hello" etc without declaring any kind of type for x. -- cheers, Hugh Fisher