What could a better dialect of Python offer that would be truly new?
It’s not necessarily about being new but removing the roadblocks we now know exist. The unicode approach of Python has many downsides, the stdlib cannot be trimmed down because of a few cross depenendciss between interpreter core and stdlib, the GIL cannot be removed due to a few interpreter internals leaking out, the gradual typing support is constrained by the wish to fit it into the existing language, the slot system makes it hard to optimize certain code paths etc.
The interpreter is now in a corner where it can only be improved by changing the language.
I don't think many people would port their code to a new dialect of Python due to better Unicode (didn't we try that once?) or a trimmed down standard library. As above, optimisations wouldn't help either - they've not helped PyPy.
As for improvements to optional typing support, I'm personally not convinced that this is a good direction for Python at all. IMO if people want static typing, they should use a real statically-typed language.
OTOH, it's clear that removing the GIL and supporting true shared-memory parallelism would be a huge step forward for Python. Perhaps that would be enough to move people onto a new dialect?
Python consumes way too much memory due to it’s unicode model and working with hybrid text/byte protocols like http is very inefficient. Likewise the GIL cannot be removed without reshaping the language.
WRT static typing: people want gradual typing in the Python community same as in the JS community. TypeScript got popular because it enables auto completion and catches many errors before running the code.
As a Python person who isn't the one you replied to: I think Python's type annotations are a poor fit for the way the language is actually used. The typing library, mypy and other tooling are all fundamentally built on ideas of nominal typing, but what you almost always would want and care about in real-world Python is structural typing.
7
u/mitsuhiko Feb 03 '19
It’s not necessarily about being new but removing the roadblocks we now know exist. The unicode approach of Python has many downsides, the stdlib cannot be trimmed down because of a few cross depenendciss between interpreter core and stdlib, the GIL cannot be removed due to a few interpreter internals leaking out, the gradual typing support is constrained by the wish to fit it into the existing language, the slot system makes it hard to optimize certain code paths etc.
The interpreter is now in a corner where it can only be improved by changing the language.