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. Cheers, Luciano On Wed, Apr 14, 2021 at 2:19 PM Brett Cannon <br...@python.org> wrote: > > > > On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher <hugo.fis...@gmail.com> wrote: >> >> On Wed, 14 Apr 2021 at 08:21, Barry Warsaw <ba...@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. > > > 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. > > -Brett > >> >> >> > 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 -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/OABB53NTCBU6EKYQVVVY4IU2275XO4R4/ >> Code of Conduct: http://python.org/psf/codeofconduct/ -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6EJBW62PJAZIOY5KELUSCQZH4JH6MALI/ Code of Conduct: http://python.org/psf/codeofconduct/
