On Mon, Apr 12, 2021 at 3: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. > 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-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/ >
_______________________________________________ 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/ZTXS5JWP5LQ3CRFTXJUREXBB3I5GQTJS/ Code of Conduct: http://python.org/psf/codeofconduct/
