Slashdot Mirror
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."
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.
It's not wasting time, I'm educating myself.
PyPy
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.
Dictionaries are for loosers.
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).
rage, rage against the dying of the light
"Doing GUI's is not the strength of any scripting language..."
;)
This is why projects like pyGTK exist
"A truly wise man realizes he knows nothing."
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.
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.
"boo", a .NET language, allows dynamic typing by specifying 'duck' type. It achieves near-c# speed because all other data are statically typed.
.NET world.
It's a great language -- combining the benefits of Python, Ruby, and C# -- and it's wonderful for proto-typing in the
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.
<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.