properties + types, implementing meta-class desciptors elegantly?

[Mike C. Fletcher]

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/