CRAZY: First class namespaces

Amit Patel amitp at Xenon.Stanford.EDU
Sun May 28 19:38:03 EDT 2000


 Christian Tismer  <tismer at tismer.com> wrote:
| 
| 
| > * Assignment to __parent__:
| > 
| >   So far I've been assuming that __parent__ is something set by Python
| >   for internal use.  For objects, it's set when you call a class
| >   constructor.  For classes, it's set when you declare the class using
| >   the "class" construct.  For namespaces, it's set when you call a
| >   function.
| > 
| >   But really, the cool stuff is really when the user can assign to
| >   __parent__!
| 
| Please drop that. The __parent__ should always be true.
| A function instance's parent namespace is always its caller.
| BTW, in Stackless, the caller can of course be assigned, but then
| it is consistent that __parent__ always walks that way.

Actually what I'm envisioning is that the __parent__ is not the
caller, but the namespace of the function that defined the current
function:

    def foo():
       x = 5
       def spam():
          print "my __parent__ is foo's namespace, and x is", x
       return spam

    foo_spam = foo()

    def zap():
       x = 9
       foo_spam()

Here, the caller of spam() is zap, which has set x=9.  However, in
lexical scope you'd print 5.  So I was suggesting that __parent__ was
set to foo, not zap.

For namespaces, it's of dubious value to assign to the parent, but
it'd be useful to assign to the __parent__ of objects that aren't
representing the local namespace.  For example, you could change your
object's class, or you can insert new classes into an existin
hierarchy.  You can also reparent an object if you're using
environmental acquisition, when the widget is moved.

	- Amit
-- 
--
Amit J Patel, Computer Science Department, Stanford University
http://www-cs-students.stanford.edu/~amitp/



More information about the Python-list mailing list