[pypy-dev] External RPython mailing list

[William Leslie]

On 16 September 2010 10:44, Hart's Antler <bhartsho at yahoo.com> 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