«

Most people are aware, if only vaguely, of the big Four Python
implementations:

CPython, or just Python, the reference implementation written in C.
IronPython, written in .NET.
Jython, written in Java.
PyPy, the optimizing implementation written in Python (actually, it's
written in a subset of Python, RPython).

But the Python ecosystem is a lot bigger than just those four. Here are
just a few other implementations that you might be interested in:


Stackless - the "forgetten Python", Stackless is, I believe, the oldest
implementation behind only CPython itself. It's a fork of CPython with
the calling stack removed and fast and lightweight microthreads, and is
used extensively in EVE Online.

http://www.stackless.com/


Nuitka - optimising Python compiler written in C++, supports Python 2.6
and 2.7, claims to be up to twice as fast as CPython.

http://nuitka.net/pages/overview.html


WPython - another optimizing version of Python with wordcodes instead of
bytecodes.

http://code.google.com/p/wpython/


CLPython, an implementation of Python written in Common Lisp.

http://common-lisp.net/project/clpython/


CapPython is an experimental restricted version of Python with
capabilities.

http://plash.beasts.org/wiki/CapPython
http://en.wikipedia.org/wiki/Object-capability_model


Berp - a compiler which works by translating Python to Haskell and
compiling that.

https://github.com/bjpop/berp/wiki



Give them some love!



--
Steven

On Sat, Aug 4, 2012 at 4:15 PM, Steven D'Aprano
<steve+> wrote:
> CLPython, an implementation of Python written in Common Lisp.
>
> Berp - a compiler which works by translating Python to Haskell and
> compiling that.

Okay. WHY? CLPython gives some reason, but how often do you need to
bridge that particular pair of languages? And why compile Python via
Haskell, when C is available as a "high level assembly language"?

The mind boggles...

ChrisA

Steven D'Aprano, 04.08.2012 08:15:
> Most people are aware, if only vaguely, of the big Four Python
> implementations:
>
> CPython, or just Python, the reference implementation written in C.
> IronPython, written in .NET.
> Jython, written in Java.
> PyPy, the optimizing implementation written in Python (actually, it's
> written in a subset of Python, RPython).
>
> But the Python ecosystem is a lot bigger than just those four. Here are
> just a few other implementations that you might be interested in:
>
>
> Stackless - the "forgetten Python", Stackless is, I believe, the oldest
> implementation behind only CPython itself. It's a fork of CPython with
> the calling stack removed and fast and lightweight microthreads, and is
> used extensively in EVE Online.
>
> http://www.stackless.com/
>
>
> Nuitka - optimising Python compiler written in C++, supports Python 2.6
> and 2.7, claims to be up to twice as fast as CPython.
>
> http://nuitka.net/pages/overview.html
>
>
> WPython - another optimizing version of Python with wordcodes instead of
> bytecodes.
>
> http://code.google.com/p/wpython/
>
>
> CLPython, an implementation of Python written in Common Lisp.
>
> http://common-lisp.net/project/clpython/
>
>
> CapPython is an experimental restricted version of Python with
> capabilities.
>
> http://plash.beasts.org/wiki/CapPython
> http://en.wikipedia.org/wiki/Object-capability_model
>
>
> Berp - a compiler which works by translating Python to Haskell and
> compiling that.
>
> https://github.com/bjpop/berp/wiki

And not to forget Cython, which is the only static Python compiler that is
widely used. Compiles and optimises Python to C code that uses the CPython
runtime and allows for easy manual optimisations to get C-like performance
out of it.

http://cython.org/

Stefan

On Sat, 04 Aug 2012 08:40:16 +0200, Stefan Behnel wrote:

> And not to forget Cython, which is the only static Python compiler that
> is widely used. Compiles and optimises Python to C code that uses the
> CPython runtime and allows for easy manual optimisations to get C-like
> performance out of it.
>
> http://cython.org/

Cython is great, but I question that it is a *Python* implementation.
That's not a criticism of Cython, but it is different from Python. Take
this example code from the tutorial:

from libc.math cimport sin

cdef double f(double x):
return sin(x*x)

If that's Python code, then I'm Ethel the Aardvark.

Cython is very Python-like, but there is no doubt in my mind that it is a
superset of Python and therefore a different language.


--
Steven

Steven D'Aprano, 04.08.2012 09:49:
> On Sat, 04 Aug 2012 08:40:16 +0200, Stefan Behnel wrote:
>> And not to forget Cython, which is the only static Python compiler that
>> is widely used. Compiles and optimises Python to C code that uses the
>> CPython runtime and allows for easy manual optimisations to get C-like
>> performance out of it.
>>
>> http://cython.org/
>
> Cython is great, but I question that it is a *Python* implementation.
> That's not a criticism of Cython, but it is different from Python. Take
> this example code from the tutorial:
>
> from libc.math cimport sin
>
> cdef double f(double x):
> return sin(x*x)
>
> If that's Python code, then I'm Ethel the Aardvark.

We never met in person, so I can't comment on the last part.

However, the above is Cython code and, yes, that's a different language.
Note that it uses a different file extension: ".pyx". Try putting the above
code into a .py file and compiling that. Cython will reject it and tell you
that "cimport" is not valid Python syntax.


> Cython is very Python-like, but there is no doubt in my mind that it is a
> superset of Python and therefore a different language.

As long as you don't use any features of the Cython language, it's plain
Python. That makes it a Python compiler in my eyes. The fact that you can
easily use C features to optimise your code (also in Python syntax, BTW)
doesn't impact that.

You mentioned a couple of other implementations and I'm sure they have
features (and bugs) that CPython doesn't have. Interaction with Lisp code
in CLPython, for example. I don't think additional features or language
implementation bugs make a Python implementation non-Python per se.

Also note that most of the less widely known "alternative Python
implementations" do not even publish their results of running the CPython
test suite, so how do you actually know they can run Python code?

Stefan

On 04/08/2012 08:49, Steven D'Aprano wrote:
> On Sat, 04 Aug 2012 08:40:16 +0200, Stefan Behnel wrote:
>
>> And not to forget Cython, which is the only static Python compiler that
>> is widely used. Compiles and optimises Python to C code that uses the
>> CPython runtime and allows for easy manual optimisations to get C-like
>> performance out of it.
>>
>> http://cython.org/
>
> Cython is great, but I question that it is a *Python* implementation.
> That's not a criticism of Cython, but it is different from Python. Take
> this example code from the tutorial:
>
> from libc.math cimport sin
>
> cdef double f(double x):
> return sin(x*x)
>
> If that's Python code, then I'm Ethel the Aardvark.
>
> Cython is very Python-like, but there is no doubt in my mind that it is a
> superset of Python and therefore a different language.
>
>

I agree so it's off topic and can't be discussed here. Isn't that
right, Stefan?

--
Cheers.

Mark Lawrence.

On Sat, 04 Aug 2012 16:34:17 +1000, Chris Angelico wrote:

> On Sat, Aug 4, 2012 at 4:15 PM, Steven D'Aprano
> <steve+> wrote:
>> CLPython, an implementation of Python written in Common Lisp.
>>
>> Berp - a compiler which works by translating Python to Haskell and
>> compiling that.
>
> Okay. WHY? CLPython gives some reason, but how often do you need to
> bridge that particular pair of languages? And why compile Python via
> Haskell, when C is available as a "high level assembly language"?

For much the same reason that PyPy uses RPython when C is available.
Because Haskell is available as a high level non-assembly language.

Berp is based on the Glasgow Haskell Compiler, which is a modern,
efficient, optimizing compiler capable of producing excellent quality
machine code on Windows, Mac, Linux and many Unixes. It gives you all the
advantages of a high-level language with high-level data structures, type
inference, and a compiler capable of generating optimized, fast, machine
code.

Who would want to deal with C's idiosyncrasies, low-powered explicit type
system, difficult syntax, and core-dumps, when you could use something
better? Apart from C programmers, of course.



--
Steven

Mark Lawrence, 04.08.2012 12:05:
> I agree so it's off topic and can't be discussed here. Isn't that right,
> Stefan?

Hmm, in case you are referring to a recent friendly and diplomatic request
of mine regarding a couple of people who were burdening a public high
volume mailing list with a purely private back-and-forth chat about having
beer and getting drunk - then, no, I don't think the discussion in this
thread qualifies as yet another example for that so far.

Stefan

Steven D'Aprano <steve+> wrote:
> Who would want to deal with C's idiosyncrasies, low-powered explicit type
> system, difficult syntax, and core-dumps, when you could use something
> better?

In the free software world, apparently many people like C. C is also
quite popular in the zero-fault software world: Several verification
tools do exist and Leroy et al. are writing a certified compiler for
C to plug the hole between the verified source code and the generated
assembly.


Stefan Krah

Steven D'Aprano, 04.08.2012 12:54:
> Berp is based on the Glasgow Haskell Compiler, which is a modern,
> efficient, optimizing compiler capable of producing excellent quality
> machine code on Windows, Mac, Linux and many Unixes. It gives you all the
> advantages of a high-level language with high-level data structures, type
> inference, and a compiler capable of generating optimized, fast, machine
> code.

Although all those optimisations don't mean that Python code would run fast
on top of it. Just because you translate Python to another language and
platform doesn't mean that there's any benefit from the underlying platform
optimisations. Both PyPy and Cython run Python code faster than CPython,
but not because they eventually translate it into machine code but because
they optimise and specialise it along the way, based on its high-level code
constructs. One big success of the Unladen Swallow project was to show that
bare JIT compilation is mostly worthless for high level languages.


> Who would want to deal with C's idiosyncrasies, low-powered explicit type
> system, difficult syntax, and core-dumps, when you could use something
> better?

The core developers of both CPython and Cython aim for exactly that. They
write C so you don't have to. But keep in mind that C is still *the* lingua
franca of software development. A major reason why Python is (slowly)
catching up these days is that the main implementation is written in C and
makes it easy to interface with C code.

Stefan