Today I stumbled upon another false positive on Mypy: https://github.com/python/mypy/issues/4660 . The issue is more than 3 years old, but it refers to a language feature (__init_subclass__) which was added in Python 3.6, released in late 2016.
I understand that maintaining a type checker is a lot of work, and requires a particular set of skills, besides interest in the subject matter.
So maybe the current state is the best we can offer.
But I do think we should mention this situation somewhere in the official documentation.
Anyone who uses a language with support for static typing expects the language distribution to include a type checker. Since that may be beyond our means, then the least we could do is have some official guidance on the matter, maybe in the form of a "Typing HOWTO" as part of the official docs, and linked from the "typing" module docs.
Such a HOWTO could provide a gentle introduction to the topic, but also cover the tools—which the existing docs and PEPs avoid. It should also explain that the tools are external, as is typeshed, which means there is always a lag between new language features and libraries and the support provided by the tools.
I volunteer to help with a "Typing HOWTO". For the next few months, I can offer to review if someone else writes it. In the second semester, I could write it myself, if the experts on typing and the type checkers would be willing to review it.
On Wed, Apr 14, 2021 at 2:19 PM Brett Cannon firstname.lastname@example.org wrote:
On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher email@example.com wrote:
On Wed, 14 Apr 2021 at 08:21, Barry Warsaw firstname.lastname@example.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.
But there are feature concerns there as well, e.g. mypy and pytype offer different "extras", even if the type checkers all align on semantics (which I know they work on in the typing SIG). There's also variance in maintenance, code complexity, etc. To me, this is not a clear-cut "mypy wins" situation.
And I know Luciano said mypy because it's "the type checker hosted in the python organization on github", but I don't know if the SC would approve that today (Guido brought mypy into the org during his BDFL days), and instead my guess is it would have ended up in the psf org like Black did.
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.
My guess is the closest we would ever come is some ensuretypechecker situation like we have with ensurepip, but pip is done that way for bootstrapping reasons and we don't need a type checker for bootstrapping.
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
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/OABB53NT... Code of Conduct: http://python.org/psf/codeofconduct/