traitlets
traitlets copied to clipboard
ipython
PEP 487
This is not really an issue, but I wasn't sure where to post it. With PEP 487 accepted into Python 3.6, it might be worth thinking about how traitlets can benefit if at all.
Since traitlets already has a framework for descriptor setup and still supports Python<3.6, we are, from my understanding, probably limited to allowing otherargs in type.__new__. However, this wouldn't be something we actually implement.
On another note though, PEP 487 implements an owner class and subclass setup phase, which is noteworthy since traitlets only implements an owner class setup phase in class_init. This suggests that a subclass setup phase (e.g. subclass_init) may be a useful feature for the same reasons __subclass_init__ is by the description of PEP 487.
@rmorshea Thanks for sharing your thoughts. Feel free to close this since this isn't a real issue :)
@NeilGirdhar though I contribute a lot here, I actually don't have collaborator access.
This brings up a good point about a subclass setup phase though. So I'd have left it all the same.
@SylvainCorlay I don't know, but the very recent discussion is here: https://mail.python.org/pipermail/python-dev/2016-July/thread.html#145466.
@SylvainCorlay When the PEP is final, it might be worth renaming the methods in traitlets to match the corresponding methods in Python 3.6? And then maybe use a more lightweight version of MetaHasDescriptors for 3.6? I wonder if this would be possible.
Yeah, I would really like to not use our custom meta class at all in Python 3.6.
(although traitlets is at the very bottom of the entire Jupyter stack so we want to be very careful with it).
@SylvainCorlay Awesome. I agree that it would be more elegant if you won't need your custom meta class at all.
@SylvainCorlay, we won't be able to switch to it any time soon. Unless a metaclass backports the features (is it possible? Anyone planning to do it?)
We could have the MetaHasDescriptors converge towards Python 3.6' s type implementation.
So, should instance_init be renamed __set_name__ and not explicitly called in Python 3.6+ (since it is called automatically on all descriptors)? Or __set_name__ could be defined and could call instance_init?
Rather, class_init would be renamed __set_name__ and subclass_init would be renamed __init_subclass__. To keep with the theme, we might choose init_instance instead of instance_init. Perhaps even __init_instance__, but the dunder name there probably isn't sanctionable (though my OCD compels me to make it so).
Wait a second, __set_name__ gets the object and the name. class_init gets the class and the name, and instantce_init gets the object. It seems like there's a different organization?
According to the PEP:
upon class creation, a
__set_name__hook is called
So it can't possibly be the obj from __get__(self, obj, cls).
@NeilGirdhar, I'm not sure if this is what you had meant, but __init_subclass__ does not do what I thought - __set_name__ is analogous to class_init, but __init_subclass__ is not analogous to subclass_init. From my understanding 3.6's data model does not supersede the need for traitlets to implement a custom metaclass.
ping: @minrk