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/ >
_______________________________________________ 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/BVQAYB4N3JKHEJ5A6NPSBKT7OWQSYQ3K/ Code of Conduct: http://python.org/psf/codeofconduct/
