properties + types, implementing meta-class desciptors elegantly?

[Mike C. Fletcher]

Beni Cherniavsky wrote:

>Mike C. Fletcher wrote on 2003-07-19:
>
>  
>
>>    * finally, stores the value
>>          o tries to do what would have been done if there were no
>>            descriptor (with the new, coerced value)
>>          o does *not* create new names in the object's namespace (all
>>            names are documented w/ descriptors, there's not a lot of
>>            '_' prefixed names cluttering the namespace)
>>          o does *not* require a new dictionary/storage-object attribute
>>            for the object (the descriptor works like any other
>>            descriptor, a *stand-alone* object that replaces a regular
>>            attribute)
>>
>>It's that last part that I'd like to have a function/method to
>>accomplish.  That is, store (and obviously retrieve as well) attribute
>>values for objects, instances, types, classes, __slot__'d instances,
>>etceteras under a given name without triggering any of the __setattr__
>>machinery which defers to the __set__ method of the associated descriptor.
>>
>>I can work around the problem by violating either of those two bullet
>>points under "finally, stores the value", but I'm looking for something
>>that *doesn't* violate them.  See below for responses to particular
>>points...
>>
>>    
>>
>I didn't grasp your precise problem but I've been having some similar
>problems (without metaclasses however).  Two tricks:
>
>- Insert a dummy class into you heirarchy between object (or whatever
>  other superclass that doesn't have the properties yet and the class
>  where you install the properties.  Then you might be able to use
>  this class to access the underliying class dict without being
>  intercepted by the properties.  [I recall some problems with
>  properties vs. super, didn't follow them closely].
>
This violates the "does *not* require a new dictionary/storage-object 
attribute" constraint.  The super-class is just another way of spelling 
"special place to store data" within the class instance, albeit a nicely 
evil one :) .  I'm looking for something that doesn't require modifying 
classes to be property-aware just to add the properties, that is, a 
stand-alone property object should be able to do this stuff w/out 
requiring that the client objects know about the properties at all.

>- If you use __slots__, they are also implemented as properties.  So
>  if you define properties with the same name in the same class, you
>  lose all access to the raw slots.  The solution is similar: define
>  __slots__ in a superclass, hide them with properties in a sublass.
>  See http://www.technion.ac.il/~cben/python/streams.py for an
>  example.
>
Will look it up.  Basically, I'm not too worried about slotted instances 
yet.  I just think it should be part of whatever general solution Guido 
figures is best.

Have fun,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/