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 <ncoghlan at gmail.com> 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 <sylvain.corlay at gmail.com> 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 | ncoghlan at gmail.com | Brisbane, Australia > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160720/cfb6bd2e/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4