properties + types, implementing meta-class desciptors elegantly?
Mike C. Fletcher
mcfletch at rogers.com
Sun Jul 20 12:54:18 CEST 2003
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
>>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
>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
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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list