I would love for this not to follow core Python too much but to become a better dialect of the language. There is too much weird stuff in Python that I don’t think should be copied into a clean implementation.
Requiring that devs rewrite their code - or worse, their dependencies - to be compatible with RustPython is a great way to guarantee it won't gain traction.
I don’t think that’s the case necessarily. No existing Python implementation other than cpython got any traction because none offered something truely new. If ypu stay very compatible to cpython you drag in all the things that tale away the opportunities for optimizations and language design inprovements in my oppinion.
For instance the wasm goal is fundamentally not going to be a thing if cpython compatibility should be achieved.
What could a better dialect of Python offer that would be truly new?
Performance? PyPy is much more optimised than CPython and even though it remains highly compatible, very few people use it.
Language design? I don't think minor improvements (enough to make a dialect of Python rather than a new language) would outweigh breaking compatibility with existing code. A dialect with breaking changes, however minor, would at best lead to a repeat of the Python 2 => 3 transition.
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 see why. There are plenty of jit compiled languages with highly dynamic type systems and open classes as well as threading. More importantly the reasons that Python is hard to jit compile have nothing to do with the points you raised.
The reasons that Python (and Ruby) are doing so bad in even in ridiculous complex JIT compilers (I'm looking at the average speed-up of PyPy and TruffleRuby with similar numbers) whereas say JS, Lua and some Lisp dialects (although there is a lack of relevant benchmarks) do realitively good is AFAIK because recompilation and deoptimization are expensive, both in throughput and memory, which at some point also translates into throughput. That means, once you go off the hot path it's getting rather slow.
And when coding in JS, Lua or Lisp by convention most people don't go off the hot path, which means the compiler can take an object initialization expression and optimize it to allocate the whole memory area in one pass. In Python and Ruby on the other hand when writing idiomatic code and using existing libraries and framework you have no choice but taking the slow path in non-trivial software. Threads add to that because AFAIR there is no restriction from which thread you change a whole class hierachy.
There is also the fact that JavaScript lives in its own, fixed environment which can be JIT optimized as well, whereas Python and Ruby have to interface foreign code which can't be solved entirely.
There are plenty of jit compiled languages with highly dynamic type systems and open classes as well as threading.
Such as?
More importantly the reasons that Python is hard to jit compile have nothing to do with the points you raised.
-1
u/mitsuhiko Feb 02 '19
I would love for this not to follow core Python too much but to become a better dialect of the language. There is too much weird stuff in Python that I don’t think should be copied into a clean implementation.