[pypy-dev] List and string in ootypesystem
Antonio Cuni
anto.cuni at gmail.com
Thu Apr 6 21:11:21 CEST 2006
Hi Armin, hi Niklaus
Armin Rigo wrote:
> I see you added SomeOOList to annoation.model.lltype_to_annotation().
> There is already a generic 'def len()' in the base class SomeObject, so
> that's how the annotator is happy with your ll function's 'len(lst)'.
> Fine here. If you wanted a .length() method instead, you would need a
> 'def method_length()' in unaryop.py.
>
> On the rtyper side, you need something similar to rpython/rptr.py that
> maps SomeOOList back to its low-level type, with yet another Repr. It's
> this repr that must implement the operations you want to be able to use
> in low-level helpers; e.g. rtype_len() if you want len(lst) to work; or
> if instead you use .length() in low-level helpers, then you would need
> an rtype_method_length() in the repr corresponding to SomeOOList (by
> opposition to the rtype_len() in the repr corresponding to SomeList).
>
> Nik's approach is to map lists to reguar OO classes and instances, which
> are already supported in the annotator/rtyper with a similarly indirect
> approach: SomeOOClass/SomeOOInstance in the annotator, which
> rpython/ootypesystem/rootype.py maps back to the low-level OO types.
> Just like rptr.py, this rootype.py is only needed to support low-level
> helpers.
Thank you for the great explanation: now I see things much more clearly,
especially the role played by rptr.py and rootype.py, which I didn't
understand very well before now.
It seems that question by question I'm really getting into PyPy's
logic... I hope I will be able to finish my apprenticeship soon :-)
ciao Anto
More information about the Pypy-dev
mailing list