[Python-ideas] Re: Should Python enforce Type-checking in the future?
Well, this has a lot of strong opinions already! I didn't expect less :-) I'm not sure how to answer so many thoughts without making this super-long. I'll try to reply in general. I agree that a compile-time python makes no sense, it would be a different language and we would lose 90% of what Python actually is. This is not what I was suggesting (sorry, I might not have been clear on my first email). I'm talking about something similar to what Typescript is. (mypy even when strict, is closer to what Typescript does than to C++/Rust) But there must be a way to skip typing altogether, both in programs and libraries. (It could also be by file extension... just suggesting more stuff here) 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. 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? And yes, types cannot cover everything. I guess this goes for any language, but especially in Python it is really impossible to type everything. But as Typescript has demonstrated (I think), having a bit of types is better than no types at all. MyPy is there for those that want to use it, of course; but needs to be promoted (this one or different tool) and encouraged. Otherwise most python libraries are just impossible to use with MyPy; and using Python without libraries is quite limiting. >> Exactly. I’ve been advocating for Python for decades — and I think that >> static type checking catches lots of bugs, but they are usually shallow >> bugs — that is most get caught the first time you try to ru the code anyway >> — or certainly if you have decent tests. > >That seems to be close to the opinion of Robert C Martin: This is not true unless your testing covers every branch in every possible state input. This also means that your unit testing in dynamic languages needs to be way more extensive than in static languages; because static checking gives you certain proofs of correctness that you don't need to test. More importantly, it removes the burden of remembering to do those test cases for those tricky scenarios. Overall, your tests will be shorter and easier to maintain. But I would say that even with extensive testing still will not cover all bugs that static type checks can catch: static type checks also can cover future bugs, not only present ones. A type check will prevent someone from calling a function/method in unexpected ways. Because type checks serve to define contracts, and 6 months later you might have forgot that the function assumed certain constraints for the input. > 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.) Anyway, I see that people are generally against what I'm suggesting. But on the other hand I also see that there are projects that are working towards faster python implementations via type-checking. I now noticed that PyPI includes filters for typed packages; I didn't recall this from 3 years ago. I wish they promoted typed ones a bit more, but well, at least we can filter. El vie, 10 dic 2021 a las 17:49, Peter Ludemann () escribió: > Steven D'Aprano wrote: > > > > That seems to be close to the opinion of Robert C Martin: > > http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html > > He also has some comments on languages like Koitlin and Swift that have > > gone down that path of
[Python-ideas] Should Python enforce Type-checking in the future?
Hi, I would like to hear the opinion of Python's community on enforcing types in the future for the language. I've been using Python as my main language for everything for around 10 years, until I started moving to Rust 2 years ago; one of the main factors was types. Just before moving to Rust I started to use mypy heavily, which I liked a lot and uncovered tons of potential problems. Now (2 years later), it seems the situation hasn't changed much; I might be wrong, so let me know what improvements you think landed in this area in the last 2-3 years. I feel it's possible this topic might cause a lot of passionate answers, but I just want to hear honest opinions on this. I firmly believe that Python's future would be better if types were enforced by default at "compile time" (whatever this means in Python), with an option/flag to disable this, and integrate MyPy or similar into the interpreter. I'm fully aware that a transition like this would be very hard and long, but I don't think it's impossible. Here's a list of my reasons to think that Python is better if it was typed: 1) On really big codebases and complex projects, it's very easy to lose track of what things do. Types help detecting bugs early. (Ask anyone that has used Rust + Clippy, the amount of errors that are catched is amazing, programs tend to work on the first try) 2) Libraries are currently the top bottleneck for any team to start using MyPy/Pytype. Making types mandatory would ensure all libraries have type support. (If anyone has any other proposal to enforce this, I would like to hear) 3) IDE integration is way simpler and better with types. 4) The interpreter could take further optimizations if it can prove that a function or piece of code is guaranteed to have a limited set of types. This could be used by libraries to have great speed ups that currently are not possible. 5) Static analysis tools could also benefit from types to gain more insight on what the code is trying to do. Of course, types have their own set of drawbacks; for example it could make Python look harder to code for newcomers, or it might get in the way for things like Jupyter notebooks, ML, and similar stuff. Because of this, an escape hatch must always exist. (maybe there are even more problems I am not aware about, I'd love to hear) If it were for me, I would like to have a Python 4 that is exactly a Python 3 but with mypy bundled and strictly enforced by default; with a flag to convert errors into warnings or disable entirely. Then every release, say a Py3.11, would also get a Py4.11-beta (the beta would be to avoid people migrating until it's ready). In this way, for a library to say it has Py4 compatibility it would need to be type-ready. Jupyter notebooks and such would be stuck at Py3, but of course, getting all the releases; and enterprises would be trying to use Py4 whenever it were ready. Typescript is also basically Javascript with types (well, not only that, but anyway) and the result is quite good. In this fashion, another alternative is having a second binary called TPython or MPython, and include it on the regular Python distribution; this would cause less push to go for types, but it could do the trick too. So well, my question here is: why is this not a thing? Has anyone proposed something like this before? I feel I must have missed something important. Thanks, David ___ 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/QBWYBXYK7NHSLQYWPV6PXAGIR4JB4FWU/ Code of Conduct: http://python.org/psf/codeofconduct/
