On 16 September 2010 10:44, Hart's Antler <[email protected]> wrote: > [the GPL] is no good for commerical software.
Please don't go there. > ... what is gained: > 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) And it's not obvious we would want this anyway, as such type information has to live somewhere, and having to carry that around makes using ints and floats more expensive. In pypy-c, small applevel ints are already tagged in the obvious way (the lowest bit of a pointer is always unset, so setting it tags an app-level integer), but rpython ints shouldn't have to live with the performance hit and additional accuracy loss where tagged ints are cast to native ints. > 3. operator overloading (except for __iter__ and __call__), PyPy only > allows overloading __init__ and __del__ Makes rtyping more work. It takes long enough as it is. > ShedSkin is behind PyPy Rpy in the following areas: > 1. no getattr, hasattr etc. Does rpython really have this? As it appears in, say, the main python eval loop, it's constant folded. This is a good example of python usage in metaprogramming rpython. > 6. multiple inheritance That would limit rpython's ability to target the CLI and JVM if implemented naeively. It's doable, but means we need to use interfaces on ootype targets and need to do more work to look up methods in the C backend - possibly implementing hotspot-style itables or virtual inheritance or passing a dictionary around. It could get ugly quickly, not only for the backends, but also for the JIT generator, which already has too much to think about in terms of the model it is implementing. > . not having to define dummy functions on the base class to prevent > 'demotion' Some concept of an interface would be handy. -- William Leslie _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
