Please, no, No, NO! It has always been the policy that typing is, and will remain, optional.
On 09/12/2021 20:32, deavid wrote:
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"
This can't be done, in view of Python's dynamic nature. As I understand it, it is impossible to check at compile time the type of an argument that is about to be passed to a function, unless it is a constant (e.g. a literal int, float, str etc.) Best wishes Rob Cliffe
(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:
- 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.
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.
Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/QBWYBX... Code of Conduct: http://python.org/psf/codeofconduct/