CRAZY: First class namespaces

Christian Tismer tismer at tismer.com
Sun May 28 15:15:53 CEST 2000


Amit Patel wrote:
> 
> I have to warn you.  This is a bit wacky, and I have no illusion that
> any of this will go into Python.  It's just some stuff that Python has
> inspired me to think about, mainly because Python exposes namespaces
> to the programmer, and programmers do cool things with it.  How far
> can that go?  (You're supposed to run away yelling when you hear
> someone say "How far can something go?")  This idea touches on
> stackless (because stack frames become objects, which are on the heap)

Yes I'm watching you :-)

> and nested scopes, too, if that'll help you run screaming.  But if
> you're ready to read some crazy stuff, here it is:

<snip size="big"/>

> * The "global" keyword:
...
>   x = 5
>   def foo():
>      def cheese():
>         global.x = 5

Looks good. Global means global, not just one world up.

> * Cycles and refcounting
> 
>   If we do nested scopes, we already get the cycles problem.  I don't
>   think making namespaces into objects makes anything worse.

I'm not sure whether this necessarily needs to create cycles.
If we don't do statically nested scopes, but just dynamically
nested scopes, the outer variables are always looked up via
the chain of running frames when this is needed, so there
will be no cycle, the same way as "self" doesn't create
cycles in the first place.

...
> * The "with" statement from Pascal:
> 
>   I suspect you can do "with" pretty easily but I'm not sure about the
>   details.  It may require multiple inheritance (aiee) if you want to
>   be able to see local variables at the same time you see an object's
>   fields.

"with" could be a construct similar to the current try..except
clauses, building a stack-like override to the __parent__ lookup.
This would create circular references in the context of the with,
which is just fine since we end the with at some time.

> * 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.

...
>      x = 5
>      def foo():
>         print x
>         x = 3
>         print x
> 
>      IMO, this should print 5 and then 3.  The unified namespace
>      proposal would do this.  However, Python currently gives a
>      NameError.

I think the current NameError is good as it is. In most cases
it shows an error in the implementation. Changing the scope of
a variable automatically would prevend optimization of locals,
and it would give more surprizes and errors than benefits IMHO.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com




More information about the Python-list mailing list