[pypy-dev] "Unwrap" Concidered Harmful

[Armin Rigo]

Hello Rocco,

On Sat, Sep 13, 2003 at 02:24:51PM -0400, Rocco Moretti wrote:
> space.is_true() is an example of such a limited use function. In my mind,
> is_true() exists for a single purpose - to determine if a wrapped
> object is true so that the interpreter can determine if a
> JUMP_IF_TRUE type branch should be taken. Any other use would be
> considered a "hack".

Right. However there are a few other cases in which the interpreter may be 
interested in "probing" information about a wrapped object. Here are two I can 
think of:

 * getting an integer. We need this at a few points, e.g. to know the exact
length of a tuple (which is needed to interpret something like "f(*args)").

 * getting a (short) string. Again there is an example in arguments decoding, 
to interpret "f(**kw)" we need to manipulate the keywords.

It may be possible to remove all these uses of unwrap (e.g. the length of a 
tuple can be obtained by iterating over it and counting), but I'd say that it 
would only make matters more obscure. Instead, just as we have "is_true()" we 
could do with a few other methods to get the integer value of an object, or 
its string value.

> Case 2
> ------
> (...)
> In implementation, y is just a proxy which passes along the
> modifications or attribute acesses to the underlying interpreter object,
> and (unwrap(wrap(x)) is x) is True.

Yes, that's the intended purpose. Application-level code that tries to 
manipulate such a "proxy" wrapped object, as in

>     fun.func_name = name

will make the object space call back to the interpreter to perform the 
operation. So the interpreter itself is free to implement the operation as it 
wishes using unwrap(fun) to get back to its own original object. This is 
similar to CPython's attribute and method tables, in which C code simulates 
what is seen at application-level as attribute reading/writing.


A bientot,

Armin.