[pypy-dev] "Unwrap" Concidered Harmful

Rocco Moretti roccomoretti at netscape.net
Sun Aug 24 03:00:58 CEST 2003


Maybe I overstate the subject line, but there are serious limitations
on the .unwrap() concept.

The limitation stems from the "blackbox" concept for object spaces. In
general, we cannot be sure that unwrap will give a valid object. It may work
for a direct representation of Python objects (such as trivial and standard
object spaces), but when we start to use object space representations that do
not exactly mirror Python semantics, unwrap isn't guarranteed to work.

For example, if an annotation-like object space represents obects as type
& bool (for truth tracking, for example), upon calling wrap(), it discards
all information about value. So there is no way we can say that
s.unwrap(s.wrap(x)) == x. Even if an object space keeps some kind of info on
the wrapped object such that it can be unwrapped, there is no guarrantee that
something valid will remain after any sort of operations on it, as a different
object space may induce a different or multiple path(s) through the code.

This is probably tractable within the object space itself, as any sort of
vagarities in the wrapping can be compensated for on a space by space basis.
However, if we wish to have a general code evaluation framework for multiple
object spaces, the code evaluation code has to be general. At the moment there
are a number of places in the code evaluation framework which call unwrap().
- I think it is mostly for unwrapping code objects.

The reason I bring this up is I think that this is the reason the general
builtin-module import code I posted earlier crashes for the annotation object
space. The code attemped to unwrap attributes of the sys module, assuming
that normal Python sematics are valid. This doesn't hold for annotation
object space ... hence the crash.

So if we wish to be general in the execution framework, we need to limit the
use of unwrap() to uses which are guarranteed to be semantically
valid by the obect space interface. (At least for the subset of object spaces
we wish to use for a particular code execution framework.)

A small but significant correllary to this is that the semantics of the
operations within a general object space should not be assumed to be
Python-like. That is, operations on object space obects should be performed
for object space effects, not for execution level effects.

This poses significant problems for the application space helpers to compute
execution level relevant results. I'm not sure how to address this yet.

-Rocco

P.S. I appologize if this has been discused before on IRC. Has any progress
been made in creating an archive of IRC logs? I get the impression a fair
number of significant points have been made on IRC, and it would be best
to archive them such that others not present can benefit from them as well.


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455


More information about the Pypy-dev mailing list