Python-to-C++ Compiler

Mark Dufour writes "Shed Skin is an experimental Python-to-C++ compiler. It accepts pure, but implicitly statically typed, Python programs, and generates optimized C++ code. This means that, in combination with a C++ compiler, it allows for translation of pure Python programs into highly efficient machine language. For a set of 16 non-trivial test programs, measurements show a typical speedup of 2-40 over Psyco, about 12 on average, and 2-220 over CPython, about 45 on average. Shed Skin also outputs annotated source code."

Very interesting...

[FuzzyDaddy]

This is a very interesting development, both from the practical promise and just 'cause it's cool. However, as a python programmer myself, it's not yet in a usable form. Much of the efficiency of programming in python is the standard libraries (in particular Tkinter for user interfaces), and the non-standard libraries (for example, the serial port library). This project does not yet support these.

Among python programmers, I'm curious - how many use psyco (another python performance enhancement tool) for their projects? I fiddled with it a while ago (it didn't work because of a C module that it didn't like), but never had a compelling reason to go back to it. Performance optimization has never been important enough for my applications to merit the effort.

Underlying technology

[Anonymous Coward]

PyPy [codespeak.net]

Re:Why not just use pure C++?

[SigmoidCurve]

bzerodi's point, made with Zen-like simplicity, is that language choice should be made to minimize programmer time, not machine time. I am at least a factor of ten more productive with Python than with C or C++. I am also far more confident in the correctness of what I write per line of Python than with what I write per line of C/C++.

Yes, I have have wasted some time staring at the shell waiting and waiting for it to return from some complicated Python routine. I know that compiled C would faster, and hand-rolled assembler would be faster still. But I say to myself: hey, I wrote this code in a single afternoon, how many weeks of hair-pulling would it take to re-engineer this - and make it bug-free - in C? When I put it that way, I don't mind waiting the extra minutes for Python to do my dirty work.

As a previous poster mentioned, the ability to handle tuples of mixed-types is critical. I look forward to seeing great things from Shed Skin in the future.

Re:Yeah, but that's not what we need.

[pthisis]

Last time I checked, it was the only Python compiler... (CPython is an interpreter, PyPy is also an interpreter

Neither CPython nor PyPy is a strict interpreter, both of them compile source to byte-code and then act as a virtual machine to run that byte-code. PyPy also does some work on compiling to native code on the fly, depending on which version you're using (Armin Rigo's is the most sophisticated on the JIT/native code front, but it's far from stable).

Re:Why not just use pure C++?

[ZephyrXero]

"Doing GUI's is not the strength of any scripting language..."

This is why projects like pyGTK [pygtk.org] exist ;)

Re:Very nice, but...

[cnettel]

Well, C# has unsafe arrays, while VB.NET only exposes them quite indirectly through the marshalling API. Some other language implementations also uses some dose of reflection/late binding to implement certain features. You can sometimes avoid use features, but this will sometimes result in code that is "non-idiomatic" in that language. I like the .NET framework, but it's no panacea for a language-agnostic future.

Re:File as NBNC (Nice But No Cigar)

[hubritc]

The way this will be used by pythonistas is not to convert 13,412 lines of code blindly in to C++. Rather, it provides a pythonic way of getting some speed benefit for those parts of the program that need it and that code will also be accessable to C++ programs as an added benefit.

Re:Speaking from experience...

[oblivion95]

"boo", a .NET language, allows dynamic typing by specifying 'duck' type. It achieves near-c# speed because all other data are statically typed.

It's a great language -- combining the benefits of Python, Ruby, and C# -- and it's wonderful for proto-typing in the .NET world.

Re:not terribly useful quite yet

[Haeleth]

I suspect that varies with the programmer. I'm pretty certain that much of my Python code contains things that a type deduction system (SML, Haskell) wouldn't be able to cope with. Certainly I use duck typing a lot.

How exactly does duck typing differ from the structural subtyping of e.g. OCaml, which allows you to write a function that can be passed any object, of any class or none, if it provides all the methods that function uses? The type inference system handles it just fine.

Of course, "duck typing" isn't a very well-defined term. Maybe your definition includes things like automatic coercions, introspection, and polymorphic recursion, which are indeed not permitted in OCaml's type system. In that case, you're probably correct in your suspicion that its benefits would not outweigh its disadvantages for you. Though you might find it useful to dabble in anyway; there's nothing so educational as frustration.

And besides, only one of maybe a hundred Python program I've written ran unacceptably slow.

<flamebait> I didn't think my old 386 was unacceptably slow, either... in the days when that was what I was used to. </flamebait>

To be fair, Python is indeed plenty fast enough, as long as all the computation-intensive stuff is happening in external libraries written in C. It's a great language for glue and GUIs (with wxPython). It does get rather slow rather quickly if you try to do anything significant in pure Python code, though.