empty classes as c structs?

[Carlos Ribeiro]

On Wed, 09 Feb 2005 21:56:54 +1000, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
> 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'.

What does PyPy do in this case? It seems that a 'namespace' class, or
at least part of its behavior, is needed there anyway... It seems to
be worth checking.

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

Another idea, maybe even more distantly related but still worthy
keeping in mind: the 'named tuples' that we talked about a few months
ago. It is in some sense a variation on some of the ideas presented
here; it is an alternative way to build simple records or bunch-like
structures.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com