empty classes as c structs?

Nick Coghlan ncoghlan at iinet.net.au
Wed Feb 9 06:56:54 EST 2005


Alex Martelli wrote:
> One thing I'd like to see in namespaces is _chaining_ -- keeping each
> namespace separate but having lookups proceed along the chain.  (The
> best semantics for _bindings_ as opposed to lookups isn't clear though).

Hmm, so if it doesn't find it in the current namespace, it looks in the parent?

For bindings, you could just go with standard Python semantics - normal name 
binding always happens in the innermost scope, so binding a name in a namespace 
should happen in the directly referenced namespace. Then you can shadow names 
from outer scopes, and later regain access to them using 'del'.

Rough concept:
   Have a '__fallback__'** attribute that is initialised to None
   Have a custom __getattr__ that falls back to the containing namespace if the 
result is not found in the current namespace.
   Have a class method which allows a namespace to be 'put inside' another 
namespace.

** Blech. Trying to add *any* state to namespace instances is going to suck. 
Maybe it would be better to just have a single __impl__ attribute and have any 
implementation related variables hang off it. This could make life easier when 
subclassing. I'm tempted to say update() should just ignore any field with a 
leading underscore by default (then we can just use normal private attributes, 
which are altered at the user's risk), but that may be too draconian.


On a complete tangent, I thought it might be worthwhile summarising the ideas 
that have come up in this thread

  - using type(self).method(self,...) as a polymorphism friendly way to access a 
class method.

  - a 'view' alternate constructor to allow manipulation of an existing 
dictionary such as globals()

  - a 'record' data type that allows the use of class definition syntax for 
simple data structures

  - lookup chaining, allowing fallback to an 'outer scope'.


Even though we'll probably end up dropping the last couple as overengineering 
things for the first pass, they're still interesting ideas to kick around.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net



More information about the Python-list mailing list