Shedskin

2007-12-07

Recently Phil Hassey from #ludumdare directed my attention to Shedskin. Shedskin is a Python to C++ compiler - so it could solve the same thing I'm currently solving with my crude line-by-line .py -> .c converter.
However, my experience with it was that it's not quite ready. It started with being hard to get running at all - I ended up copying the lib folder and the FLAGS file from the original distribution into my project. Also, it is all but obvious to me how to interface external libraries. I ended up manually keeping 3 files, a .py, a .cpp and a .hpp in sync, editing each one for each function to add. This is what stopped me from actually doing much at all with it, it's clearly too painful to be useful that way. Maybe a way could be found to directly let me use external code instead? I call libc.printf, and it puts a call to printf. At the most, there should be a single description file where I specify the necessary header stdio.h and the types (and maybe also the library?) Editing three files for each symbol is almost as bad as manually using the Python-C-API. Also, again packaging related, there needs to be sane way to incorporate shedskin into my projects, the generated makefile and FLAGS file won't cut it at all.
Furthermore, one of the main reasons I prefer C over C++ is compile time. This was already noticeable with my shedskin test - gcc needed several seconds just to compile the code produced by shedskin for the short test program and library wrapper, likely because it's somehow pulling in lots of headers. My reference code doing the same only takes an instant from .py (reg-exped to .c) to the executable. Additionally, the Shedskin website says that it will need increasingly longer for the type inference with growing number of lines, so with a real program, that may add a lot more time even. Not compatible with my rapid testing way of coding.
Finally, I don't think type inference is very important for me personally. With dynamic code, it is nice that I can just throw around objects of different types and let everything be sorted out where I want, even using techniques like duck typing. With static code, seeing what types are needed actually can be an advantage sometimes - else I manually would have to add comments about the types or do manual type inference. So, for now, shedskin is not for me.