In any case I find this PEP great. If we can implement a library like traitlets only using these new hooks without a custom metaclass, it will be a big improvement.
My only concern was that calling the hook __set_name__ was misleading while it could not set the name at all and do pretty much anything else. Regards, Sylvain On Thu, Jul 21, 2016 at 4:53 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > 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