On Sat, Dec 11, 2021 at 7:44 AM deavid <deavidsed...@gmail.com> wrote: > When I said earlier in "compile time", I was just trying to refer to the > parsing step, or pre-parsing step. Or maybe means that "python a.py" => "mypy > a.py && python a.py". > I'm being very ambiguous here on purpose because there are tons of ways to do > this and "how to do it" or the cons of a particular method aren't something > that I wanted to discuss, I just wanted to get a general idea of where the > community stands. >
You could make a shell alias that does that, if that's what you want. > A lot of you are referring to scripting, learning, and other ways of using > Python that would be badly impacted. I already acknowledged that these exist > (or at least I didn't notice here any other that I wasn't aware), and that's > why I mentioned that there should be a way to avoid type-enforcing for these > scenarios. Maybe by flag, by Python version, file extension... The method > doesn't matter much at this moment. > If it were "easy" to continue writing the old programs without types, what's > the problem in trying to make types more popular? > Or by simply running Python without first running MyPy. That's a method. > > Another project you may want to look at is MyPyC [1], which is similar > > in concept but takes a different approach; it compiles type-annotated > > Python to CPython C extension code. MyPyC is much more mature and > > something you could easily try out today. > > [1] https://github.com/mypyc/mypyc > > There you have it. I'm amazed that this is already a thing and the discussion > of "enforcing types" didn't happen up to now. > If MyPyC can compile to C and get a 4x performance boost, it means that > Python is leaving a 4x boost on the table. When creating the bytecode (old > *.pyc files) Python could create for some functions a second one that > internally doesn't use Python objects, for those cases where the types > actually match. And the GIL could be released (sometimes) during the > execution of those. > (It might look that the above statement is far too simplistic. But it should > be roughly true with lots of caveats.) > >From the MyPyC docs: """These are our near-term focus areas for improving mypyc: * Improved compatibility with Python""" The 4x speed boost is only if you restrict yourself to the things it can handle. That's fine if a project specifically chooses to do that, but not for general work. And it is definitely NOT a reason to push type checking into the core language. Side question: What if someone wants to use a different type checker than MyPy? Why should that one single checker be blessed with language support? Type annotations are intended to be there for *every* type checker to use. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NCZZZNH34SNOZZ434GFKEMI5OCA4XHQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
