A lot of keynotes lately have been about how we need a new python implementation, and have included the

By Wikipedia’s programming languages classification system, this might make this new implementation a dialect; of which Python already has several.

The platform: WebAssembly

WebAssembly is a moving target.

It might make sense to start with Transcrypt? So we have something working?

What is Elm waiting for?

Outline:

What might the new implementation be like?

• the platform, very roughly: compiled!

• well where do existing dialects differ?

• go through each of them

• the platform, in detail

• Elm’s approach

• Should we be on the cutting edge?

• change

Here’s a quick tour of differences.

CPython

What you think of as Python; the reference implementation; the one whose core developers suggest that we

Think beyond CPython!

Don’t target bug-for-bug compatibility with CPython!

MicroPython

Very low RAM

Starlark

A quite limited mostly-subset of Python used for configuring [a build system](https://en.wikipedia.org/wiki/Bazel_(software).

RPython

I think there’s going

In fact, the mypy project (supported by Dropbox) does have something.

One candidate is mypyc. As of this writing, mypyc:

• does not implement a bunch of things
• no metaclasses
• I forget what else

But we have living, popular Python implementations already that make these tradeoffs:

MicroPython: diff stdlib maybe?

Starlark: removed tons of things, adds freezing; not faster, just more deterministic

?:

From most similar to CPython to least

• CPython
• PyPy
• Jython
• MicroPython
• mypyc

put these on a graph to show the tradeoff: the further it is from CPython, the greater the advantage over it needs to be AND all the old attempts have been too close to CPython

There have been alternative implementations of Python before. I remember the warnings that “although my open().read() calls would work fine in CPython, that I might leave a dangling open file handle if I didn’t explicitly close the file object in Jython.