<div dir="ltr">Hi Nick,<div><br></div><div>Thank you for your reply. I understand your argument about <span style="font-size:12.8px">using protocol method names that are</span></div><span style="font-size:12.8px">very specific to a particular intended use case.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Sylvain</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 20, 2016 at 6:22 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sylvain,<br>
<br>
Thanks for getting in touch! The traitlets library sounds interesting,<br>
and provides good additional evidence that this is a capability that<br>
folks are interested in having available.<br>
<span class=""><br>
On 20 July 2016 at 15:26, Sylvain Corlay <<a href="mailto:sylvain.corlay@gmail.com">sylvain.corlay@gmail.com</a>> wrote:<br>
> My understanding is that the proposed __set_name__ in PEP487 exactly<br>
> corresponds to our class_init, although interestingly we often do much more<br>
> in class_init than setting the name of the descriptor, such as setting a<br>
> this_class attribute or calling class_init on contained descriptors.<br>
> Therefore I do not think that the names __set_name__ or __set_owner__ are<br>
> appropriate for this use case.<br>
><br>
> In a way, the long-form explicit names for our class_init and instance_init<br>
> methods would be something like __init_fom_owner_class__, and<br>
> __touch_instance__.<br>
<br>
</span>It's certainly a reasonable question/concern, but we've learned from<br>
experience that we're better off using protocol method names that are<br>
very specific to a particular intended use case, even if they can be<br>
adapted for other purposes. The trick is that we want educators<br>
teaching Python to be able to very easily answer the question of "What<br>
is this special method for?" (even if they later go on to say "And<br>
it's also used for these other things...")<br>
<br>
One previous example of that is the __index__ protocol, where the<br>
actual semantics are "instances of this type can be losslessly<br>
converted to integers", but the protocol is named for the particular<br>
use case "instances of this type can be used as sequence indices".<br>
<br>
For PEP 487, the two operations guiding the naming of the methods are<br>
"notify a base class when a new subclass is defined" and "notify a<br>
descriptor of its attribute name when assigned to a class". The<br>
precise verbs then mirror those already used in other parts of the<br>
related protocols (with __init__ leading to __init_subclass__, and<br>
__set__ leading to __set_name__).<br>
<br>
The main capability that __set_name__ provides that was previously<br>
difficult is letting a descriptor know its own name in the class<br>
namespace. The fact a descriptor implementor can do anything else they<br>
want as a side-effect of that new method being called isn't<br>
substantially different from the ability to add side-effects to the<br>
existing __get__, __set__ and __delete__ protocol methods.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span></blockquote></div><br></div>