[pypy-dev] Re: "Unwrap" Concidered Harmful

Michael Hudson mwh at python.net
Tue Sep 2 16:10:06 CEST 2003

Armin Rigo <arigo at tunes.org> writes:

> Hello Rocco,

Oops, I've been meaning to reply to this too...

> On Sat, Aug 23, 2003 at 09:00:58PM -0400, Rocco Moretti wrote:
>> Maybe I overstate the subject line, but there are serious limitations
>> on the .unwrap() concept.
> Yes, I agree with your analysis. I actually think that we are using unwrap() 
> for different purposes at different places, and we should clearly mark these 
> differences...


>> all information about value. So there is no way we can say that
>> s.unwrap(s.wrap(x)) == x.
> I am now coming closer to the idea that wrap() should be redefined
> as well, because it is used not only on simple types but also on
> "internal interpreter structures", like code objects plus others
> more internals than that.


> In summary we'd have two usages for wrap()/unwrap() -- let's try to
> figure out some better names:
>  * wrap(x) -> create a blackboxed reference for the interpreter object x
>  * unwrap(w_x,ExpectedType) -> inverse of the previous operation
>  * newint(i), newstr(s)... -> create simple object space objects

(note this is like a bit like Py_BuildValue in the C API)

I'd *much* rather write space.build(1) than space.newint(1).

This would be a convenience method that takes a fixed set of types
(maybe just integers and strings...).

>  * unwrap(w_x,int), unwrap(w_x,str) -> inverse of the previous operation


If we have different calls to unwrap doing radically different things,
I think they should have different names...

> In this idea, unwrap() would be a bit like PyArg_ParseTuple in that
> it would check what type of interpreter-level object it is supposed
> to return, possibly raising a TypeError.
> Still this doesn't directly address the whole issue of
> application-level helpers. I tend to think now that we should be
> very careful before using app-level helpers.

It seems that way.


  Good? Bad? Strap him into the IETF-approved witch-dunking
  apparatus immediately!                        -- NTK now, 21/07/2000

More information about the Pypy-dev mailing list