Strategies for controling attribute assignment

[Tim Peters]

[Dale Strickland-Clark, on a 2.2 "property" example]
> I can't confess to understanding that entirely but it looks
> interesting.
>
> There's some interesting new stuff in 2.2 but I missed this. I
> look it up.

This isn't your fault, it's ours:  we're still dead busy implementing all
this great stuff, and producing user-friendly documentation is on hold until
it's all there.  Guido got a good start on a tutorial, though:

    http://www.python.org/2.2/descrintro.html

If you're an "under the covers" type, this is the heart of it:  if you're
trying to get an attribute A from a new-style instance I, A is first looked
up in I's class's dict.  *If* A is found in the class dict, *and* A's value
V in the class dict has a __get__ attribute, then V.__get__ is called to
handle the attribute access.  Similarly if you're trying to set an attribute
A, or delete it, from a new-style instance I, and A is found in the class
dict, and A's value V there has a __set__ attribute, V.__set__ is called to
handle it.  Thus setting, getting and/or deleting a specific attribute can
be customized in any way you can write code to express, and each attribute
can do it differently (if it wants to).

On the one hand that's all there is to it, and things like the new builtin
property(), staticmethod() and classmethod() functions merely exploit it in
straightforward ways.  Indeed, you could easily enough write those yourself,
and in Python, if you wanted to.

OTOH, kinda like the metaclass hook, the lowest-level __get__/__set__
protocol is so simple that it's mind-twisting at first (which is partly why
we're packaging the property() etc functions for instant out-of-the-box
use).

I don't think it will happen for 2.2, but Guido isn't opposed to adding new
syntax to make whatever prove to be the most popular gimmicks of this nature
more palatable.