properties + types, implementing meta-class desciptors elegantly?
Michael Hudson
mwh at python.net
Tue Jul 22 09:48:28 EDT 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