[Python-ideas] Simpler Customization of Class Creation - PEP 487

Martin Teichmann lkb.teichmann at gmail.com
Mon Feb 8 08:16:29 EST 2016


Hi Sjoerd, Hi List,

> It would cause backwards-incompatibility, but would it not be an option
> to call __get__ and __set__ (and __del__) with an extra parameter: the
> name of the attribute that is supposed to be accessed? (This can
> probably be worked around by inspecting the signature of __get__/... to
> see how many arguments it takes).
>
> Because right now, if the descriptor itself does not maintain any state,
> it is possible to assign the same descriptor to multiple class
> attributes, maybe even to multiple classes. (On the other hand, in that
> case it would probably not need `__set_owner__` either).

I think the backwards-incompatibility is a show stopper for this idea.
I actually think it's a good idea, but too late. I checked PEP 252, which
invented __get__, and it also states that every attribute should have
a __name__ and __objclass__. But it is silent on how an attribute should
acquire that. __set_owner__ fills this silence.

We could try to actually implement PEP 252 and set __name__ and
__objclass__. I guess this would give a big backwards compatibility
headache. We could require descriptors to inherit from a class
types.Descriptor, and set the __name__ and __objclass__ only on
them. That's a little less flexible than the current proposal.

> The question to me is: can __set_owner__ give us something that can not
> be done by adding a name parameter to __get__/... . The weakref proxy
> (with callback) looks to be one of those cases, but is not really:

Well, __set_owner__ gets called much earlier. This means we might
avoid having to write some lazy initialization code. I know, that is a weak
argument, but I think it's actually nicer to have a __set_owner__ method
over having an overloaded __get__. But this "nice" certainly is a question
of taste.

Greetings

Martin


More information about the Python-ideas mailing list