Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Some More Information

Freddie
2005-09-18
2013-04-09
  • Freddie
    Freddie
    2005-09-18

    Hi! I am really interested in your project, it seems amazing. However I would like to find out some more about it, like what it supports and what it does not. I know that there will be lots of limitations (better stop using eval and exec) but I would like to know just what is and is not support. Mainly the stdlib of python and if it all needs to be ported over (which could take a long time).
    While I can not really help with the project (I am a C dude) I would love to find out more about it.

     
    • Mark Dufour
      Mark Dufour
      2005-09-20

      Hey there! Sorry about the slow reply. I don't check these forums often. Maybe I should.

      Yeah, I'm a C dude too. I don't need all the flexibility of Python. The syntax and the dynamic typing are fantastic by itself. It would be great if you could use these two and still have your code run really fast. This is the goal of Shed Skin.

      See the README in 0.0.2 for a detailed (but incomplete) list of limitations. You can also look at the programs in 'unit.py' to see what kind of programs are typically supported now. (e.g. see tests 30, 34, 37, 99, 122, 123 using 'python unit.py -p nr > filename')

      About the stdlib, yeah, at this point I have only implemented some calls that are common in algorithms (math.sqrt, random.random..), but each other call has to be 'type-modeled' in Python and implemented/bridged in C++. It may be possible to automate this process, based on the 'type-model' code, by autogenerating calls to CPython, but I won't be working on this anytime soon. For now, again, mostly algorithmic code is supported, which typically doesn't have many dependencies. Anyway, each external call just has to be modeled/implemented once.. e.g. for math and random this is really easy.

      thanks!
      mark.

       
    • Gal Koren
      Gal Koren
      2005-10-15

      Is this gonna be THE python compiler everybody expecting for...? oh... (yea!) Why not?!
      As soon as the CPython's standard modules would be (automaticaly!!!) importable, it'd be the greatest.
      I'd love to help as soon as I finished my FLAMEingo within few months. Wait for me!

       
    • Mark Dufour
      Mark Dufour
      2005-11-05

      heya,

      sorry for the delayed reply. I'm not used to people actually posting stuff here :D to answer your question, no, SS will probably always be a niche compiler. if you want to have support for the full Python language, and easy importing of anything, your best bet is probably to wait for the release of PyPy. SS is really a much simpler system, but with some limitations. I built it to be able to convert C++-like algorithms from Python to C++, in essence allowing one to specify C++ programs at a higher level. as time goes by, it will probably support more and more of Python, but really dynamic stuff such as reflection, eval, changing parent classes, etc, will probably never work. it also remains to be seen whether I will be able to continue working on it, because it's mostly working out a heap load of boring details. I can be motivated very much by code contributions and small code snippets that fail :-) especially optimizations on the C++ implementation of the Python builtins would be very welcome (I would love to look into this myself, but I have my hands full atm.. :-))

      thanks!
      mark.