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:
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/
_______________________________________________
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/C73JYWGDXPWKHHMFQZ3OQNGKKJFYBUSA/
Code of Conduct: http://python.org/psf/codeofconduct/
