> Message: 1
> Date: Sun, 11 Apr 2021 13:31:12 -0700
> From: Barry Warsaw <barry@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.
Please don't denigrate the hard work people have put in to even bring forward the idea of typing in Python by saying it's "slightly ridiculous".
-Brett
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-leave@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/