Re: [Python-Dev] PEP487: Simpler customization of class creation
Hi Sylvain, Thanks for getting in touch! The traitlets library sounds interesting, and provides good additional evidence that this is a capability that folks are interested in having available. On 20 July 2016 at 15:26, Sylvain Corlay wrote: > My understanding is that the proposed __set_name__ in PEP487 exactly > corresponds to our class_init, although interestingly we often do much more > in class_init than setting the name of the descriptor, such as setting a > this_class attribute or calling class_init on contained descriptors. > Therefore I do not think that the names __set_name__ or __set_owner__ are > appropriate for this use case. > > In a way, the long-form explicit names for our class_init and instance_init > methods would be something like __init_fom_owner_class__, and > __touch_instance__. It's certainly a reasonable question/concern, but we've learned from experience that we're better off using protocol method names that are very specific to a particular intended use case, even if they can be adapted for other purposes. The trick is that we want educators teaching Python to be able to very easily answer the question of "What is this special method for?" (even if they later go on to say "And it's also used for these other things...") One previous example of that is the __index__ protocol, where the actual semantics are "instances of this type can be losslessly converted to integers", but the protocol is named for the particular use case "instances of this type can be used as sequence indices". For PEP 487, the two operations guiding the naming of the methods are "notify a base class when a new subclass is defined" and "notify a descriptor of its attribute name when assigned to a class". The precise verbs then mirror those already used in other parts of the related protocols (with __init__ leading to __init_subclass__, and __set__ leading to __set_name__). The main capability that __set_name__ provides that was previously difficult is letting a descriptor know its own name in the class namespace. The fact a descriptor implementor can do anything else they want as a side-effect of that new method being called isn't substantially different from the ability to add side-effects to the existing __get__, __set__ and __delete__ protocol methods. Cheers, 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
Re: [Python-Dev] PEP487: Simpler customization of class creation
Hi Nick, Thank you for your reply. I understand your argument about using protocol method names that are very specific to a particular intended use case. Interestingly, the one example that is provided in the PEP is that of a "trait" which is pretty much the same as traitlets. (traitlets started as a pure python implementation of Enthought's traits library). 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. Cheers, Sylvain On Wed, Jul 20, 2016 at 6:22 PM, Nick Coghlan wrote: > Hi Sylvain, > > Thanks for getting in touch! The traitlets library sounds interesting, > and provides good additional evidence that this is a capability that > folks are interested in having available. > > On 20 July 2016 at 15:26, Sylvain Corlay wrote: > > My understanding is that the proposed __set_name__ in PEP487 exactly > > corresponds to our class_init, although interestingly we often do much > more > > in class_init than setting the name of the descriptor, such as setting a > > this_class attribute or calling class_init on contained descriptors. > > Therefore I do not think that the names __set_name__ or __set_owner__ are > > appropriate for this use case. > > > > In a way, the long-form explicit names for our class_init and > instance_init > > methods would be something like __init_fom_owner_class__, and > > __touch_instance__. > > It's certainly a reasonable question/concern, but we've learned from > experience that we're better off using protocol method names that are > very specific to a particular intended use case, even if they can be > adapted for other purposes. The trick is that we want educators > teaching Python to be able to very easily answer the question of "What > is this special method for?" (even if they later go on to say "And > it's also used for these other things...") > > One previous example of that is the __index__ protocol, where the > actual semantics are "instances of this type can be losslessly > converted to integers", but the protocol is named for the particular > use case "instances of this type can be used as sequence indices". > > For PEP 487, the two operations guiding the naming of the methods are > "notify a base class when a new subclass is defined" and "notify a > descriptor of its attribute name when assigned to a class". The > precise verbs then mirror those already used in other parts of the > related protocols (with __init__ leading to __init_subclass__, and > __set__ leading to __set_name__). > > The main capability that __set_name__ provides that was previously > difficult is letting a descriptor know its own name in the class > namespace. The fact a descriptor implementor can do anything else they > want as a side-effect of that new method being called isn't > substantially different from the ability to add side-effects to the > existing __get__, __set__ and __delete__ protocol methods. > > Cheers, > 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
Re: [Python-Dev] PEP487: Simpler customization of class creation
On 21 July 2016 at 03:40, Sylvain Corlay 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
Re: [Python-Dev] PEP487: Simpler customization of class creation
Whoa. That's not how I read it. --Guido (mobile) ___ 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
Re: [Python-Dev] PEP487: Simpler customization of class creation
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 wrote: > On 21 July 2016 at 03:40, Sylvain Corlay 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
