[pypy-dev] External RPython mailing list

[Saravanan Shanmugham]

----- Original Message ----
> From: Hart's Antler <bhartsho at yahoo.com>
> To: pypy-dev at codespeak.net
> Cc: Saravanan Shanmugham <sarvi at yahoo.com>
> Sent: Wed, September 15, 2010 5:44:35 PM
> Subject: Re: External RPython mailing list
> 
> Porting ShedSkin to use the PyPy translation toolchain on the surface sounds  
>like a good idea, but its not if we look at the details.  The first issue  is 
>legal, PyPy is MIT licensed, which works very well when integrated by  
>commerical software.  But Shedskin uses the GNU GPL3, so importing any of  its 
>code (or code that imports GPL code, etc) into the user's compiled program  also 
>binds it to the GPL - which is no good for commerical software.   Shedskin 
>within the PyPy toolchain may taint the users program with GPL code  because 
>some RPython programs will import from rlib (which may in someway depend  on 
>Mark's GPL code).

Sarvi: Good point. I hadn't noticed that the generated C++ code was GPL.
I think Mark might be open to MIT licesing the generated C++ code. Coz, without 
it Shedskin as a tool chain would make no sense.
But then thats a different story.

Either way, it looks like there i not much enthusiasm for porting Shedskin on 
PyPy and have pypy generate a compiler instead of an interpreter.

>From various threads on python.org as well pypy itself, I see a lot of interest 
in a compiler for a staticaly typed subset of python.
I also feel that a statically typed subset of python can be faster than the 
dynamic superset. 

Which is why I have exploring options to spur some interest to drive some 
momentum in this area. Hasn't been easy.

I can see why some might feel that RPython is not for general use and only for 
language development. 

But what totally surprises me though is that as a language developer, I would 
want RPython to be as flexible as possibile within feasibility of course.

Anyway, I am going to keep it simple and just start exploring just expanding on 
PyPy's RPython compiler to make it more general purpose.

yes, on a separate branch :-))  of ofcourse. :-)

I'll start with some of the items below.

Lets see where that can go.

Sarvi


> 
> The second issue is technical, not much is gained  for the likely great amount 
>of effort it would take to merge ShedSkin.   Lets look at what is gained:
>     1. muteable  globals
>     2. None and (int,float) are intermixable as  attributes on an instance 
>because ShedSkin has some limited support for  dynamic-sub-types.  (PyPy can not 
>mix None with int and  float)
>     3. operator overloading (except for __iter__ and  __call__), PyPy only 
>allows overloading __init__ and __del__
> 
> #1, would be  nice to have but its an easy workaround to use singleton 
>instances.
> #2, no  big advantage.
> #3, this is a big advantage, i wish i could at least overload  __getattr__ in 
>PyPy Rpy.
> 
> ShedSkin is behind PyPy Rpy in the following  areas:
>     1. no getattr, hasattr etc.
>      2. *args        (Mark says he can bring it back  but only for homogenous 
>types (PyPy supports *args with non-homogenous  types))
>     3. passing method references
>      4. no interface to C
>     5. mixed-type tuples are limited to  length two (PyPy allows for any 
>length)
>     6. multiple  inheritance
> 
> The ShedSkin readme itself states that " the type inference  techniques 
>employed by Shed Skin currently do not scale very well beyond several  hundred 
>lines of code" and recommends ShedSkin only for small programs.   Not having the 
>6 items above are additional reasons why ShedSkin is not ideal  for writting 
>large programs, these are serious limitations for a large program,  especially 
>#4 - not having a easy way to interface with C is a huge  show-stopper; PyPy Rpy 
>has an amazingly simple way to interface with C  (rffi).  The other 
>dissadvantages of ShedSkin are: slow object allocation  (Phil Hassey did a test 
>showing ShedSkin 30% slower than RPython), and it only  translates to C++ while 
>PyPy can translate to C, Java, and #C.
> 
> There are  simple ways to improve PyPy Rpy that will benifit both the PyPy 
>project and  those who strictly want to use the translation toolchain.  I've 
>been  following the progress of this years Google Summer of Code projects, and i 
>see a  big stumbling block for everybody was RPython.  PyPy today would have a  
>better 64bit JIT, faster ctypes, and better numpy support if RPython was itself  
>better.
> 
> RPython Wishlist:
>     .  documentation
>     . iteration over tuples of any length (with  any mixed types)
>     . overloading __getattr__,  __setattr__
>     . pickle support, if its limited thats  ok.
>     . rstruct is incomplete
>     . llvm  backend, what happened to llvm support?
>     . not having to  define dummy functions on the base class to prevent  
>'demotion'
>     . not having to use the hack `assert  isinstance(a,MySubClass)` to call 
>methods with incompatible  signatures.
>     . we already have the decorator:  @specialize.argtype(1), why can't we have 
>@specialize.argtype(*) so that all  arguments can have flexible types?
>     . methods stored in a  list for easy dispatch can not have mismatched 
>signatures.
> 
> I aggree with  Fijal, CPython module extension should be a low priority.  There 
>is a big  speed overhead when passing data back and forth from CPython, and 
>speed is the  whole point of going through the trouble of writting in RPython.  
>Those who  are less concerned with speed and want CPython module extensions can 
>use Cython,  which is well tested.  Those who are interested in RPython and want 
>a  simple way to get started can use ShedSkin to make an extension module, and 
>then  migrate their module to a standalone app with PyPy if they  choose.
> 
> -hart
> 
> 
> 
>