[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...
Yup.
>> 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.
[snippety]
> 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
unbuild?
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.
Cheers,
mwh
--
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