IMHO, mentioning MicroPython is a plus because it's a mature project with a focus not covered by any of the other mentioned implementations.

PR adds the mention.

A reasonable suggestion. Let's make sure that we mention CircuitPython as well.

IIRC, Guido recognized only PyPy, Jython, and IronPython as alternate conforming implementations.   A number of other projects were python-like but were also going off in their own directions not subject to his pronouncements.

MicroPython is a pretty cool project but I don't think that its goal is for most code written for CPython would run on MicroPython or vice-versa.

That said, somewhere in the docs (a FAQ entry) there should be a list some of pythonesque implementation like MicroPython, CircuitPython, CPython, VPython, etc.

IMO, the Language Reference is the wrong place.  That document (which used to be subtitled "for language lawyers only") is intended to be the most precise and offical specification of the Python language.  It doesn't make sense to reference implementations that don't follow the specification.

Addenda:  Somewhere in the annals of our history this was discussed before (perhaps dating back to Stackless Python).

Sorry, I didn't knew that :) I'll update the PR adding an entry in the FAQ.

With "CPython" in "pythonesque implementation like MicroPython, CircuitPython, CPython" did you mean Cython?

Thanks Raymond :-)

The FAQ seems like a good place to share. Cython would be a nice addition and perhaps IPython too.

What do you think about also mentioning Skulpt and Brython? On one hand, they -like MicroPython/CirtcuitPython- cover a focus no other implementation does (and a special one: client side Web scripting); but on the other hand, we shouldn't make space for everybody to add her/his pythonesque implementation.

I think your suggestion for Brython and Skulpt is excellent. I believe that it's important to point out that Python can be used client-side, and both your suggestions have been around for a while, are stable, and often used in large courses such as OpenEdX.

I have updated the PR with a FAQ that mentions all implementations mentioned here, except Cython and Stackless Python.

I added RapydScript as it's used by VPython for Web visualization, in the category of client-side scripting pythonesque languages/implementations.

I didn't add Cython because it's not clear to me if it's useful for creating extension modules in a pythonesque language, or if it's also useful by it's own.

I didn't add Stackless Python because it doesn't fit with the "problem domain specific" category I've chosen for the FAQ.

I'm pretty sure this will need a few iterations, but at least we have an starting point :)

> I didn't add Cython because it's not clear to me if it's useful for creating extension modules in a pythonesque language, or if it's also useful by it's own.

Cython only makes extensions for CPython, and uses CPython's runtime. But it does have its own syntax, which is quite useful in the number-crunching domain.

I think it should be left out, but then, so should VPython which seems like it's a module usable by either the CPython or RapydScript interpreters.

Thanks for the PR, and thanks everyone for the feedback.

But I don't think we should be the one maintaining a list of all available alternative Python implementation out there.

There is already a good list: https://wiki.python.org/moin/PythonImplementations which is the top result when people search for "Python implementation".

I'm inclined to close this issue.