On 21 July 2016 at 03:40, Sylvain Corlay <sylvain.cor...@gmail.com> wrote:
> My point is that in any real-world implementation of traits, __set_name__
> will do a lot more than setting the name, which makes the name misleading.
I suspect the point of disagreement on that front may be in how we
view the names of the existing __get__, __set__ and __delete__ methods
in the descriptor protocols - all 3 of those are in the form of event
notifications to the descriptor to say "someone is getting the
attribute", "someone is setting the attribute" and "someone is
deleting the attribute". What the descriptor does in response to those
notifications is up to the descriptor, with it being *conventional*
that they be at least plausibly associated with the "obj.attr",
"obj.attr = value" and "del obj.attr" operations (with folks voting by
usage as to whether or not they consider a particular API's side
effects in response to those notifications reasonable).
The new notification is merely "someone is setting the name of the
attribute", with that taking place when the contents of a class
namespace are converted into class attributes.
However, phrasing it that way suggest that it's possible we *did* miss
something in the PEP: we haven't specified whether or not __set_name__
should be called when someone does someone does "cls.attr = descr".
Given the name, I think we *should* call it in that case, and then the
semantics during class creation are approximately what would happen if
we actually built up the class attributes as:
for attr, value in cls_ns.items():
setattr(cls, attr, value)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
