On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann <lkb.teichm...@gmail.com> wrote: >> When I first wrote PEP 422 I was of the view that "Python 2 allows >> class definition postprocessing injection, we should allow it in >> Python 3 as well". I've since changed my view to "Having to declare >> post-processing of a class definition up front as a decorator, base >> class or metaclass is a good thing for readability, as otherwise >> there's nothing obvious when reading a class definition that tells you >> whether or not postprocessing may happen, so you have to assume its >> possible for *every* class definition". > > Nick, I couldn't agree more with you, yet I think PJ actually brought > up a very interesting point. Post-processing is a very common thing > these days, and has been re-written so many times that I think it is > about time that something like it should be in the standard library. > > I'm less thinking about decorated methods, more about descriptors. > They always have the problem that they don't know which attribute they > belong to, so every author of a framework that defines descriptors > writes a metaclass which goes through all the descriptors and tells > them their attribute name. > > I propose to have some metaclass in the standard library that does > that. I think it would fit nicely in my metaclass module proposed in > PEP 487. > > It would basically do the following: > > class Metaclass(type): > def __init__(self, name, bases, dict): > super().__init__(name, bases, dict) > for k, v in dict.items(): > if hasattr(v, "__post_process__"): > v.__post_process__(k, self) > > So each descriptor could define a __post_process__ hook that tells > it the attribute name and also the class it belongs to. This would for > sure also work for decorated methods. > > This should mature on PyPI, then introduced into the standard library, > and if demand is really that high, maybe even be introduced into > type.__init__. It should be noted that this can also be easily written > as a PEP 487 class using __subclass_init__, I just used the classical > metaclass notion as I guess people are more used to that. > > This proposal can actually be seen as an extension to the __class__ > and super() mechanism of normal methods: methods currently have the > priviledge to know which classes they are defined in, while descriptors > don't. So we could unify all this by giving functions a __post_process__ > method which sets the __class__ in the function body. This is about the > same as what happened when functions got a __get__ method to turn > them into object methods.
I've felt for a long time that it would be helpful in some situations to have a reverse descriptor protocol. What you are describing it a strict subset of that concept (which is fine). It may be worth considering a method name that would also be used for that more generic reverse descriptor, rather than having 2 names for the same thing. Even if such a protocol never materializes, the name borrowed here would still be informative. -eric _______________________________________________ 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
