[pypy-dev] Re: appspace considerations and genrpy

holger krekel hpk at trillke.net
Thu Dec 2 01:03:12 CET 2004

Hi Jacob, hi all, 

[Jacob Hallén Thu, Dec 02, 2004 at 12:36:52AM +0100]
> torsdagen den 2 december 2004 00.12 skrev Christian Tismer:
> > Ok. But another thing that annoys me is that this macro language
> > still has rpythonic restrictions, when I use the unmodified
> > flow space. I think it should be full Python.
> > I had the strong feeling that I did a whole mess with no real
> > benefit. But I might be wrong.
> I think we need to define what RPython really is. Probably this is best done 
> by maintaining a list of what limitations relative to Python there are. 
> Initially, this list does not need to be exhaustive. Anything we know about 
> restrictions will help.

Do you realize that in 


further down at "Object Restrictions" there is a basic list of 
rpythonic restrictions?  

I presume, the underlying restrictedpy.txt documentation could be 
enhanced from the experiences and enhancements at the last sprint, though. 

However, as long as we don't have a fully translated PyPy, we probably 
cannot fully complete the list. 

> It is really hard to write any RPython if you don't know the limits and it is 
> equally hard to know what to translate if you don't know which constructs 
> that need the translation.

With the above mentioned list we already should have most of
what the restrictions on our Python usage are. Btw, IMHO we should 
always talk about restrictions to python usage, rather than 
talking about "RPython" as if it were some weird new language.  

One open topic regarding the restrictions is how to handle *args 
and **kwargs calls.  We did a number of hacks at the last sprint 
to the flowobjspace and annotation to make them "work".  But 
it's not satisfactory and produces quite a bit of the warnings 
that you see when running translate_pypy.py. 

Another open topic are dictionaries.   We discussed an idea on IRC 
that dictionaries should only be statically prebuilt and not dynamically
generated.  But maybe this is not practical and we will
eventually need to improve the annotator to handle dynamically
built dictionaries.  

However, i am currently only aware of one truly dynamic usage
of a dictionary which is in the Arguments class of the
interpreter.  Incidentally, this is connected to the other
*args/**kwargs calling problem and thus we might try to solve
both problems at once ... 



More information about the Pypy-dev mailing list