properties + types, implementing meta-class desciptors elegantly?
Mike C. Fletcher
mcfletch at rogers.com
Tue Jul 22 00:11:14 EDT 2003
Bengt Richter wrote:
>On 20 Jul 2003 09:39:51 -0400, aahz at pythoncraft.com (Aahz) wrote:
>
>
...
>I was wondering if Mike was wanting to have class C(...) with property p
>(meaning the property object is an attribute of class C or a base), and
>wanting also to have the instance dict contain the data as c.p rather
>than, say, c._p.
>
Well, that's a regular property. I have lots of those. I'm looking for
a meta-property here.
>IOW, does he want a sneaky way to avoid seeing the underscored or otherwise
>modified names in the object, so as to have a clean dir(c)?
>
Yes, that's part of it.
>Other than the problem of getting the class defined in a dynamically configurable way
>via metaclasses or other machinery, c.__dict__['p'] = value_from_property_fset should
>work, IWT. The code below does that, though a little more parameterized ;-)
>
Yup, it all works fine for regular instances, the question is, how to do
it for classes in a way which as closely as possible mimics what is done
with instances. Michael's code is, AFAICS so far, the only stuff that
yet addresses this.
>What I'm not getting is why a dict proxy is getting in the way, unless there is an
>attempt to use the property mechanism to store properties-as-values in a class-as-instance.
>
Precisely that. Using the same general mechanism, properties of a class
modifying instances of that class, in this case, the class is a
meta-class and the instances are regular classes. The problem is that
the dict-proxy of classes gets in the way of this rather straightforward
combination of the two concepts of "property" and "metaclass".
>If so, does he (continuing 3rd person since I'm replying to AAhz. Hi Mike ;-)
>
Hi! :)
>really want
>all that dynamic meta-stuff to happen every time a class is instatiated, or should the
>classes-to-use be created once at some configuration time (maybe system start or other
>special times), and thereafter appear to be equivalent to plain valnilla manually written
>classes with properties?
>
I think you're imagining much simpler usage patterns than I am. The
basicproperty hierarchy includes such things as lazy
calculation/retrieval of values from database, default-value calculation
in the abscence of explicit settings, logging/change notification,
etceteras. I want to make those services available for the dynamically
loaded plug-in classes (as distinct from instances of those classes) in
such a way that it seamlessly integrates with the rest of the system and
doesn't warp the code too horribly.
The only thing blocking that from happening is a low-level way to
set/get attributes in a class' __dict__ without triggering the
__setattr__ machinery. This is a deficiency in the Python descriptors
API that I'd like to see fixed.
The plug-in classes do tend to have large numbers of regular (non-meta)
properties as well, BTW, but that's not interfering with anything.
>If the latter, some kind of factory module that manufactures configured classes with
>configured properties and puts them in its global name space to be used in apparently
>normal "import m; inst=m.C()" fashion would seem better than metaclass inheritance magic behind C.
>If there are other configuration times than first-import, the module could have a special
>factory functions for that, IWT (as in cpc.py below). The properties of the final
>configured/manufactured classes could of course act with any degree of dynamism desired
>when accessed as attributes of the final class instances.
>
Not what I'm trying to do. I have lots of mechanisms for dynamically
creating instance properties from a database, creating them from
data-structures, or creating them as names in class namespaces as per
normal. That stuff all works fine, it's the meta-properties which cause
problems.
>BTW, do I recall somewhere seeing that defining __dict__ as a slot induces creation of
>a writable dict, and could that be used to get a dict in place of proxy for the trouble spot?
>
Nope, __slots__ doesn't work with type objects.
>For Mike:
>
>What does the following not address (I assume you can rearrange things to your taste ;-)
>that you want to do? (InfoSource is my placeholder as an example for whatever dynamic
>configuration of the ultimate class you want to do).
>
<snip>
It doesn't create active properties on the class instances
(meta-properties) (as far as I can see, anyway). See my response to
Michael's post for an example of what's being attempted.
BTW, sorry for not responding immediately, it often takes me a while to
sit down and work through large posts with lots of code to work through
to understand the point of the post. Michael's code was short enough
that I could dash off a response before dinner, while yours was
considerably more involved and required me to set aside time to work
through what you were doing and asking.
Enjoy,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
More information about the Python-list
mailing list