properties + types, implementing meta-class desciptors elegantly?

Michael Hudson mwh at python.net
Tue Jul 22 15:48:28 CEST 2003


"Mike C. Fletcher" <mcfletch at rogers.com> writes:

> Michael Hudson wrote:
> 
> >Michael Hudson <mwh at python.net> writes:
> >
> >  
> >>"Mike C. Fletcher" <mcfletch at rogers.com> writes:
> >>
> >>    
> >>>So, does anyone have a pattern which allows setting an attribute on
> >>>a class which doesn't go through the setattr machinery (i.e. can be
> >>>used within a descriptor)?
> >>>      
> >>No.  Fun problem to think about, though :-)
> >>    
> >
> >Actually, that was a lie.  Check this horror out:
> >
> <snip>
> 
> >I'm quite proud of this one :-)
> >
> Rightly so, all evil geniuses should always gloat over their mad
> creations :)
> 
> Unfortunately, it appear to tickle a Python 2.2.3 bug where setting
> a descriptor on a meta-class doesn't reinstate capturing of the
> __get__ for the attribute.  I filed a bug report for that here:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=775328&group_id=5470&atid=105470

And I'll close it again: MetaProp is a non-data descriptor, and hence
overridden by the contents of __dict__.  Adding a dummy __set__ to the
MetaProp in the bug report makes the asserts pass.

> Other than that, and it's intrinsicly *evil* nature, it does,
> indeed, do what I was looking for.

I actually thought that the automatic __dict__ overriding was part of
what you were looking for!

> BTW, you're creating a property whose *value* (albeit a static value)
> is shared by all instances of the meta-class, rather than one that's
> specific to the individual class.

Well, yah.  Making an interesting property *value* didn't seem to be
the point of the excercise :-)

[...]
> But really, I don't think either of us will deploy that particular
> pattern in a production system.  

Phew :-)

> Still, fun proposal, thanks for playing, we have lots of marvelous
> parting gifts for you :) .
> 
> BTW: You know this, but in case others are wondering why it's not
> usable in real life: it's possible to have threads get/set the value
> without triggering the descriptor if they happen to ask for it during
> the period when the descriptor is deleted.

That's one of the obvious flaws, yes.  You could up the insanity
quotient still further by having a per-property-instance Lock() around
the descriptor machinations :-)

Another, more serious (to me, given that I don't use threads) is the
lack of coping with inheritance.

Cheers,
mwh

-- 
  we're already scrubbing the face of intuition with steel wool,
  setting it on fire, then putting it out with an axe <wink>.
                      -- Tim Peters, on comparing recursive structures




More information about the Python-list mailing list