properties + types, implementing meta-class desciptors elegantly?

Mike C. Fletcher mcfletch at rogers.com
Sat Jul 19 11:49:25 EDT 2003


Michele Simionato wrote:
...

>I agree with Bengt, from your traceback it seems you are assigning directly
>to client.__dict__, but you cannot do that (I think because client.__dict__
>is a dictproxy object and not a real dictionary). The right way to
>go is via object.__setattr__ , or type.__setattr__ in the case of
>metaclasses.
>
Try this to see what I'm getting at:

 >>> class o(object):
...     class p( object ):
...         def __set__( self, client, value, *args, **named ):
...             print '__set__', self, client, value, args, named
...             # now what do you do here to set without triggering 
ourselves
...             # (without having to code diff versions of the 
descriptor class
...             # for each possible type of client object (and for that 
matter, just
...             # making it possible for (meta-)types with properties 
w/out requiring
...             # e.g. a new dict object in each such serviced type))?.
...             return object.__setattr__( client, "v", value)
...     v = p()
...
 >>> s = o()
 >>> s.v = 3

You'll notice you go into an infinite loop.  What I'm looking for 
(really a thinly veiled attempt to get other people to demand it from 
Guido so he doesn't think I'm a lone crackpot ;) ) is a function/method 
that provides the default implementation of the get/set functionality 
*below* the level of the descriptor hooks, but high enough that it can 
deal with the differences between classes, types, instances, and 
instances-with-__slots__ (I realise that last one probably isn't going 
to work, BTW).

Thought of another way, it's asking for a superclass of descriptors 
which provides this logic in such a way that, by sub-classing from them, 
you can readily gain access to this descriptor-building functionality 
without needing to always use it, and without introducing unwanted 
restrictions (such as requiring a property-class initialisation).

Thought of another way, it's asking for a further rationalisation of the 
get/set hooks so that there's a lower level at which you can either 
insert storage code *or* use the default storage code.

>I guess you are aware of the metaclass+properties recipes in the
>on-line cookbook, but just in case ...
>
Hadn't looked at them, have now, there's nothing which addresses this 
particular issue that I can see with a search for metaclass.  Willing to 
be proved wrong :) .

Have fun,
Mike

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








More information about the Python-list mailing list