Re: [pypy-dev] Restricted language
Armin Rigo <arigo@tunes.org> wrote: < excellent discussion of confusion between (host) Python and (interpreted) Python snipped >
Here we are using Python's __getitem__ protocol to implement Python's __getitem__ protocol. I see nothing wrong in that, but it is easy to get confused. To make things clearer I would way:
self.valuestack.push(w.getitem(v)) ...
Think about the type() function; it could not return the real type of the implementing object, because you couldn't implement lists or ints with a custom class. And it cannot call a new method __type__() of the object, because you cannot add such a new method to all already-existing built-in objects. You could hack something that calls __type__() if it exists and returns the real type otherwise, but you are running into trouble when interpreting programs that define __type__() methods for their own purpose. This is the kind of confusion we are bound to run into if we are not careful.
So if I understand you correctly, we should not use (either explicitly or implicitly) any of the special methods of the objects we create for the interpreter. The only acceptable use is member dereferencing (object.attribute). Only host objects are allowed to be part of special method use. (e.g. in function calls, in expressions such as a+b, etc.) This is not strictly a technical limitation in most cases, but good practice so that we avoid confusion between the two levels. Is this an accurate interpretation? -Rocco P.S. In your implementation of EPython exceptions, how would associated traceback objects be handled? __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Hello Rocco, On Mon, Jan 20, 2003 at 10:39:04PM -0500, Rocco Moretti wrote:
So if I understand you correctly, we should not use (either explicitly or implicitly) any of the special methods of the objects we create for the interpreter. The only acceptable use is member dereferencing (object.attribute).
Yes, indeed. To avoid confusion the host objects (CPython objects) should not define special methods. We should define our own set of methods, althought it can be as straightforward as using the canonical name and dropping "__". So custom list implementations would define a "getitem()" method and not a "__getitem__()" one. Another way to see this important distinction is by closely following the CPython core declarations. Wherever there is a "PyObject*", it means that the core is handling an application-level object (which we have to translate into an application-level object, like an ImmediateObject). Wherever there are other C data types, it is interpreter-internal data. The application-level "__getitem__()" method corresponds to: PyObject* PyObject_GetItem(PyObject* object, PyObject* index); This function is not called "__getitem__"; there is only a similarity in the name. The function does not take an integer index (i.e. an "int"), but an application-level "PyObject*". It is exactly the same in our case: we need a "getitem(self, v_index)" method whose name merely reminds us about "__getitem__", and taking as index argument not an integer, but another object implementing an application-level object (which might be an ImmediateObject() containing an integer).
P.S. In your implementation of EPython exceptions, how would associated traceback objects be handled?
If we decide to use attributes of the EPython instance to store the application-level exception type and value, then the traceback could also be there. In the main loop, when an EPython exception is caught, its traceback info would be updated. In fact this description is just what one would explain to describe what the PyTraceBack_Here() call in ceval.c does. A bientôt, Armin.
participants (2)
-
Armin Rigo -
roccomoretti＠netscape.net