[pypy-dev] Re: appspace considerations and genrpy
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
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
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