I see multiple problems with including a type checker as part of the standard
library:
First of all this would require defining precise type checking semantics and
not making breaking changes to them. Currently some parts of type checking are
not precisely defined and are done differently by different type checkers. Take
this example:
if condition:
a = 1
else:
a = "foo"
reveal_type(a)
Mypy raises an error at the second assignment and infers a as int. Pyright on
the other hand doesn't report errors and infers a as Union[int, str].
Both approaches are equally valid and have their advantages and drawbacks.
My second concern would be the development speed. Python type checking is still
relatively young and is developing at a vastly different rate from the rest of
the language. While cpython currently has a 1 year release cycle mypy had 5
releases (excluding minor releases) in the last year.
This development speed difference can also be seen by the use of
typing_extensions to back port typing features to older python versions.
GitHub search shows 16.500 python results for "from typing_extensions"
(excluding forks).
Being tied to the cpython release cycle would probably significantly hinder the
development of a type checker.
I agree that a delay between a python release and mypy (and other type
checkers) supporting it isn't optimal, but it can probably be solved much
easier: By having more developers put in work to keep it up do date.
This work would still need to be done, even for a type checker that's part of
the standard library.
The only difference would be that changes would then cause tests in cpython to
fail instead of just in mypy.
In the future, when development on type checkers has slowed, adding a type
checker to the standard library might be useful, but in my opinion it would
currently do more harm than good.
Adrian Freund
On April 13, 2021 11:55:05 PM GMT+02:00, Luciano Ramalho <luci...@ramalho.org>
wrote:
>Hugh was unfortunate in presenting the problem, but I agree that we
>should commit all the way to supporting type hints, and that means
>bundling a type checker as part of the standard library and
>distribution.
>
>There is always a delay after a Python release before Mypy catches up
>to—and that's the type checker hosted in the python organization on
>github.
>
>I believe this is an unfortunate state of affairs for many users. I am
>not aware of any other optionally typed language that underwent core
>changes to support type annotations and yet does not bundle a type
>checker.
>
>Cheers,
>
>Luciano
>
>
>
>On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher <hugo.fis...@gmail.com> wrote:
>>
>> > Message: 1
>> > Date: Sun, 11 Apr 2021 13:31:12 -0700
>> > From: Barry Warsaw <ba...@python.org>
>> > Subject: [Python-Dev] Re: PEP 647 Accepted
>>
>> >
>> > This is something the SC has been musing about, but as it’s not a fully
>> > formed idea, I’m a little hesitant to bring it up. That said, it’s
>> > somewhat relevant: We wonder if it may be time to in a sense separate the
>> > typing syntax from Python’s regular syntax. TypeGuards are a case where
>> > if typing had more flexibility to adopt syntax that wasn’t strictly legal
>> > “normal” Python, maybe something more intuitive could have been proposed.
>> > I wonder if the typing-sig has discussed this possibility (in the future,
>> > of course)?
>>
>> [ munch ]
>>
>> >
>> > Agreed. It’s interesting that PEP 593 proposes a different approach to
>> > enriching the typing system. Typing itself is becoming a little ecosystem
>> > of its own, and given that many Python users are still not fully embracing
>> > typing, maybe continuing to tie the typing syntax to Python syntax is
>> > starting to strain.
>>
>> I would really like to see either "Typed Python" become a different
>> programming
>> language, or progress to building type checking into the CPython
>> implementation
>> itself. (Python 4 seems to me the obvious release.) The current halfway
>> approach
>> is confusing and slightly ridiculous.
>>
>> The first, a separate programming language, would be like RATFOR and CFront
>> in the past and TypeScript today. Typed Python can have whatever syntax the
>> designers want because it doesn't have to be compatible with Python, just as
>> TypeScript is not constrained by JavaScript. A type checker translates
>> the original
>> Typed Python source into "dynamic" or "classic" Python for execution. (Maybe
>> into .pyc instead of .py?)
>>
>> This would mean no overhead for type checking in CPython itself. No need to
>> contort the parser into ignoring bits of code that are, in effect,
>> syntax checked
>> comments. And for the typing in Python enthusiasts, you won't have to listen
>> to people like me complaining.
>>
>> The second approach is to assume that type checking in Python is useful and
>> popular. Not with me, but I'm willing to accept that I'm in the minority and
>> can
>> be ignored - after all, I can still write my Python code without type
>> annotations.
>> If so running a type checker as a separate step, as we do at the moment, is
>> like asking C programmers to run the preprocessor by hand.
>>
>> In today's world of continuous build and integration, it seems silly
>> to me to have
>> a type checker read the source, scan into lexical tokens, build an
>> abstract syntax
>> tree, perform semantic analysis with type checking, and then throw it away
>> before running an interpreter which reads the same source, scans into lexical
>> tokens, builds an abstract syntax tree, and executes. On the purely pragmatic
>> level there is an extra chance for mismatches and things to go wrong; and
>> from
>> an environmental viewpoint it isn't a great use of resources.
>>
>> --
>>
>> 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/2DMJPVE4T6SMXIPQJVWOOSYWJX6DA22H/
>> 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/FAYGAU72I3LJGZRFQNM4UFDGREYYI5WZ/
>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/DR57TJQI3WUUBFFFGP3LVF624LVRSZGI/
Code of Conduct: http://python.org/psf/codeofconduct/
