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/
