properties + types, implementing meta-class desciptors elegantly?
Mike C. Fletcher
mcfletch at rogers.com
Sun Jul 20 10:55:35 EDT 2003
Aahz wrote:
>In article <mailman.1058654317.6488.python-list at python.org>,
>Mike C. Fletcher <mcfletch at rogers.com> wrote:
>
>
>> * 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)
>>
>>
>
>But this is a recipe for name clashes. If you follow the first bullet,
>it's a normal attribute, but everything else says you want a property.
>Properties are themselves objects that are attached to names in an
>object. You can't have the same name bound to two different objects.
>
>
It's true that:
* your class has a namespace, and there are objects stored in that
namespace
o the objects stored in that namespace often are descriptors
o they are available to the instances which do not shadow them
(as I said, I can deal with this, and it's cleaner anyway).
+ if they are descriptors, they modify instance access
to attributes
* you can't have a property object in the class namespace if you're
storing the meta-class property-value there
o *unless* the value is the property (perfectly reasonable
value to store for the meta-class property)
* the metaclass properties are stored in the metaclass' dictionary,
so they don't conflict with metaclass instances' values for the
properties
* the metaclass instance's property *values* would be stored in the
metaclass instance's dictionary, just as is normally done (the
metaclass' property *descriptors* would be stored in the
metaclass' dictionary), there's no new conflicts created here,
everything just works like it does now, a lookup would look
something like this:
>>> x.y
x doesn't have a __getattribute__, so see if it has a descriptor for 'y'
get type(x).y
type(x) doesn't have a __getattribute__, so see if it has a
descriptor for 'y'
get type(type(x)).y -> this is just a simple descriptor, as
there's no higher-level descriptor, has a __get__ method,
calls it to retrieve type(x).y
returns the currently stored entry 'y' in type(x)'s dictionary,
which happens to be a descriptor
has type(x).y, a descriptor with a __get__ method, calls it, gets
back value stored in instance's dictionary
returns the value of y stored in the instance dictionary
You wind up with some names that are not available for use *as
properties* on instances *iff* you set a simple value for the properties
of the meta-class instance, but you solve that the regular way, by
making the value stored by the meta-class instance's property a
descriptor, rather than a simple value. That's just the way classes
work. Yes, it's a "name clash", but everything in classes/instances is
name clashes <shrug>.
Not a problem I can see in the problem I outlined just yet, there's
still no low-level value-setting mechanism exposed,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
More information about the Python-list
mailing list