Home Original page

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