I agree that showing support for type hints is important, as long as this doesn't convey the counterproductive message that type hints have become almost mandatory. They are useful in some circumstances, and less so (specially when dealing with beginners or non-professional programmers) in others.
I don't agree that mypy should become part of the standard lib.
1) It's already obvious that it's the prefered implementation (in Python - there are at least 3 other implementations that are not written in Python and/or not open source that have an impact on the market).
2) Mypy is already part of the Python organisation on GitHub, it's even one of the 6 featured repositories (which means it probably has a top-level status with the PSF).
3) But it has a release cycle that is shorter than Python. It hasn't even reached 1.0 !
4) If we are to "commit all the way to supporting type hints", a first step IMHO would be to type hint all the standard library. AFAICT, type hints for the stdlib are currently supported in the typeshed project, which is also a top-level project. But I have not checked if it covers 100% of the stdlib.
Also, one could argue that the stdlib type hints should live closer to the stdlib itself, and have a release cycle aligned with that of the stdlib, and that typeshed should be reserved for type hinting popular third-party libraries.
Indeed, if there was a proposal to make, mine would be to do exactly this :)
On Tue, Apr 13, 2021 at 11:58 PM Luciano Ramalho email@example.com 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.
On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher firstname.lastname@example.org wrote:
Message: 1 Date: Sun, 11 Apr 2021 13:31:12 -0700 From: Barry Warsaw email@example.com 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
language, or progress to building type checking into the CPython
itself. (Python 4 seems to me the obvious release.) The current halfway
is confusing and slightly ridiculous.
The first, a separate programming language, would be like RATFOR and
in the past and TypeScript today. Typed Python can have whatever syntax
designers want because it doesn't have to be compatible with Python,
into .pyc instead of .py?)
This would mean no overhead for type checking in CPython itself. No need
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
to people like me complaining.
The second approach is to assume that type checking in Python is useful
popular. Not with me, but I'm willing to accept that I'm in the minority
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,
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
before running an interpreter which reads the same source, scans into
tokens, builds an abstract syntax tree, and executes. On the purely
level there is an extra chance for mismatches and things to go wrong;
an environmental viewpoint it isn't a great use of resources.
cheers, Hugh Fisher
Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at
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 -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/FAYGAU72... Code of Conduct: http://python.org/psf/codeofconduct/