Shed Skin is an experimental Python-to-C++ compiler. It can convert many Python programs into optimized C++ code, without any user intervention such as adding type declarations. Its main purpose is to optimize algorithmic-like Python code, by applying advanced global type inference techniques.

I'm fed up with slow bash/perl/whatever system scripts. When init starts or scripts do some heavy processing, it's slooooooooow. Something that _should_ work good in theory IMO almost always sucks in the real world.

If you have heavy processing that is performance critical, a scripting langauge may well limit performance. That hardly makes scripting langauges useless. Typically, a line of a high level scripting language can replace 5-10 lines of C or C++. Since you have to pay for programming (time or money), scripting languages can be an efficient use of programmer time.

Here we a developer giving us a free tool that allows us to write Python and get C++'s performance. You have stated the obvious and he has done something to address the issue.

I meant ", too" The tool is nice, and I think it should help moving away from executing e.g. data processing by the slow interpreter (those SuSE config scripts take forever to complete). Anyway, even nonoptimizing converter is good, because g++ will optimize the code if necessary.

The speed of Bash, etc, is almost never the actual problem. The actual problem is usually that system startup involves lots of disk I/O through a cold cache, which is pretty much the slowest thing you can do on a computer. Even if the script was 10x as fast, it'd still spend 99% of its time sleeping.

Very very good point. The other problem is bootup is done in a serial fashion, even if apache is sleeping as it's starting up, nothing else can procede until it's done. People like to bitch that python/perl/interpreted language X are slow and bloated. If it were slow nobody would use it.

What do you think a compiler is? This is a compiler, plain and simple. Lots of compilers target C instead of ASM, usually because that way they don't have to implement all the optimizations the C compiler does. They're still compilers.

Donít get too excited yet. From what I understand this version supports only a C++ like subset of Python (whatever exactly that means) not the whole of Python. As cool as this is, and I really do think it is damn cool, I probably will still take some time before you can use it to convert a Python program that wasnít written with conversion to C++ in mind.

Many thanks to Mark Dufour. A very cool project. I wonder if it might be possible to generalize something like this more, like converting Parrot Code, which is supposed to be an intermediate language for a slew of scripting languages, to C++, and thus take care of Python, Ruby, Smalltalk, etc in one step.

Parrot isnít that hot anymore. Most people in other language cams got their own thing, and lots of Perl people are falling out with the way things look for them (Perl 5 is dead, Perl 6 not in sight, and Parrot appears to be to bloated since it tries to produce a VM for all, but nobody is interested).
The >>one VM for all<< idea isnít all that popular. Just look at how much people bitch about .NET. But anyway this was about Python not about the large amount of other languages out there.

I think the cooling off of excitement over Parrot, Perl 6, and all of that is just due to people being sick of waiting for them to become production ready. People need solutions now, and Parrot just isn't here yet.

The "one VM for all" idea is extremely popular, look at all of the language implementations that run on .NET and the Java VM (including Iron Python and Jython respectively). If you don't believe me, google for it. Before you dismiss Jython, it is extremely popular, and stands a good chance of becoming part of a future Java release.

The people bitching about .NET are mostly bitching because it is a Microsoft technology. Everyone I know who has actually sat down and tried to write something in C# has been thoroughly impressed, it is an incredibly fluid and intuitive programming language. I am by no means a Microsoft fanboy, but I will admit that Microsoft hit the nail on the head with C# and .NET. It is a drastic improvement over traditional Windows development tools. Another group of people who bitch about .NET are the VisualBasic developers, but that's just because MS made some major and not backwards compatible changes to their pet language, to shoehorn it into the .NET runtime.

Another argument for "one VM for all" comes on the server side of things. Say you need to run a Python app, a Perl app, a PHP app, and a Java app all on the same server. Your memory usage is going to go through the roof, as are the number of processes you need to run. (Yes I know PHP, Perl, and Python can be run via Apache modules, but you still get my point.) Another problem is trying to get all of these disparate server processes to talk to each other in a clean manner. Not to mention that from a network administrator's perspective, configuring, securing, and maintaining such a setup is nothing short of frustrating.

The idea of >>one VM for all<< as I called it is enticing for lots of people. Mono went for it and it might not be that bad for them since there are a few languages being used on it, but still mostly only MS languages and then still only mostly C#. On Mono you will see the same thing C# is the dominant language there. But of course you CAN run other languages on .NET and Mono. Same thing goes for Java, you have scheme for it, python for it, ruby for it and groovy and what not. I think all of them are damn good alternatives to Java and I know at least ruby and python additionally to java so I could go all out and program in ruby or python on Java. But I donít. Other programs for the JVM are, hold your seats, programmed in Java. As a fact the JavaVM is shockingly almost purely used by programs made in Java.

And there you have it. An one for all VM will be ruled by its dominant language and so lots of the supposed benefits just donít exist. Why is this so? Well for one Jython != Python. I would have to port any program from Python to Jython do to stuff like API soandso not being implemented or being implemented different, my program making assumptions that are true under Python but not under Jython and last but not least, different GUI toolkits. As a >>one for all VM<< Java has failed but thatís not so bad since it never really was intended for that no mater how many other languages target the JavaVM. .NET and Mono have a different problem; the VM expects languages to fallow certain rules of the VM. This pisses lots of people of since their language of choice will need adapting to the VM and some of the APIs go byby since you are now coding .NET. So .NET and Mono fail because the languages need to adapt to the VM and programmers arenít to happy about their languages loosing their individual flavor to the degree that .NET requires.

But fortunately Parrot is different; it tries to provide an environment where the VM has everything that Perl5, Perl6, TCL, Scheme, Basic, Ruby and Python could possible need. Yes it is truly the >>one VM for all<< just that Ruby is doing their own VM and donít give a shit. Python is more interested stuff like PyPy and nobody cares much about TCL or Basic anymore. Well altheas Perl5 can interact with Perl6 and new programming languages like Amber right?

Multi language VMs are hyped up a lot thanks mostly to .NET, but they donít deliver what they promise. And with Parrot it lead to a VM that is more complicated then it needs be to accommodate other languages that are just not interested in running on Parrot.

The people bitching about .NET are mostly bitching because it is a Microsoft technology.

Not exactly, even though I'm one of them I don't care if this MS tech or Sun tech or whoever tech

Everyone I know who has actually sat down and tried to write something in C# has been thoroughly impressed, it is an incredibly fluid and intuitive programming language.

Same thoughts exactly. That's why tried harder than other languages I tried

I am by no means a Microsoft fanboy, but I will admit that Microsoft hit the nail on the head with C# and .NET. It is a drastic improvement over traditional Windows development tools.

No arguing here, in fact I agree 100%

Another group of people who bitch about .NET are the VisualBasic developers, but that's just because MS made some major and not backwards compatible changes to their pet language, to shoehorn it into the .NET runtime.

Not me.

Another argument for "one VM for all" comes on the server side of things. Say you need to run a Python app, a Perl app, a PHP app, and a Java app all on the same server. Your memory usage is going to go through the roof, as are the number of processes you need to run. (Yes I know PHP, Perl, and Python can be run via Apache modules, but you still get my point.) Another problem is trying to get all of these disparate server processes to talk to each other in a clean manner. Not to mention that from a network administrator's perspective, configuring, securing, and maintaining such a setup is nothing short of frustrating.

Ok, here we are. I don't care how many VM or whatever. What turned me off .NET is sloppy memory handling. I wouldn't even care if I would write desktop software, but since I'm writing server services that run 365/24 and so far I must say I had no problems in maintaing this result. Even though C# and .NET are beatifull and everything else would lead only to benefit me I had to drop the whole thing. On heavy load every service just consumed all RAM and SWAP and only after that started dribling between working and cleaning (restarting whole thing was the only option). As long as you write application that has idle time everything is perfect, even application that has heavy load job like renderer for example causes no problems (all these applications don't have long run and most of the software time is idle time waiting on user input), there's always enough time for garbage collector to do its work and so it waits with this task until too late.

The same as test of speed between C and .NET or Java (where magically java and .net won). Again, always they use allocating and freeing memory in their examples for the sole reason that freeing never happens in Java or .NET during timing (and it is time consuming), while C has a downside of actualy executing that. Same test with a lot bigger number shows the actual result. Just make in the same test a little change in for loop to go to 2^32 and speed test will become more accurate without doing any favours to any language

Maybe it is just me, but I asked a lot of people and no answer and solution. The only answer I got was to drop .NET and went back to the languages where I can control everything. Now, anyways it is too late until my next project.

Final thoughts: If I would be writing user apps I would probably (or more like 100%) move on .NET and Mono and I even suggest to people that do write them to look at Mono and MS.NET, but since this is not the case... well, you can't expect from me to not criticize something (that would be both java and .NET) that doesn't allow me what other languages allow without any hassle.

I think that other proyect that with some future is PyPy[1]: Python coded in Python. The basic idea is to try make a Python interpreter in Python, not in C like the original CPython. So you can work in a higer level lenguaje and try to make athomatic translator of Python into other languajes like C, LISP and the LLVM opcodes. Also the project will introduce some ideas developed in other projects like Stackless Python and Psyco (a Python JIT with some profiling)

Tcl has critcl and Perl has the Inline family of modules which let you run another language inside your script. Take Tcl and Critcl for example. If there is something you want to happen in C, you just put that code in your script do a "package require critcl" and boom that portion is passed to the C compiler creating calls that Tcl can use. Perl's Inline modules do just about the same thing.

From page 1 of "Compilers: Principles, Techniques, and Tools":
"Simply stated, a compiler is a program that reads a program written in one language - the source language - and translates it into an equivalent program in another language - the target language."

So, python being the source language, and C++ the target language, this is a compiler by definition.

I've been trying Shed skin since the first day and and so far, I'm very impressed and satisfied.

It's important to note that at its current stage, shed skin should be used to convert and compile python programs written in a relatively "static" style. That means that you should avoid dynamic features such as exec or eval. Also, you shouldn't change the type of a variable like this:

a=5
a='is now a string'

Also, it worth mentioning that it is not possible to import modules or using the standard library at this moment, since any module should be written in the above mentioned static style in order to compile.
In few words, try to design your program the same way you should when using a static language, but taking advantage of the beatufull and productive python syntax (no type declarations, readable code, etc).

I'd also like to say that Mark has been very kind and responsive to my questions and he is very fast at fixing bugs and implementing missing features.
He would also appreciate any help from interested developers to continue developinh Shed Skin.
It seems that all the hard work and the basic functionality has already been done and implemented, but now a lot of work remains to be done for getting into details.
As far as I could see, it would be very easy for experienced c++ and/or python programmers to contribute to the project.