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