[pypy-dev] "Unwrap" Concidered Harmful

Rocco Moretti roccomoretti at hotpop.com
Mon Oct 13 15:53:51 CEST 2003

Armin Rigo wrote:

>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.
I'd argue that the interpreter level length of an argument tuple should 
be determined by a specific function, and not by unwrapping the 
application level length. We may want to implement some object space 
where the application level length is different than the length at which 
the intepreter should view it. For example, an application level length 
may be "between 4 and 7, but most likely 5", but for purpouses of 
interpreter level execution we want it to be treated as 7.


More information about the Pypy-dev mailing list