On Fri, Apr 3, 2015 at 8:44 AM, Martin Teichmann <lkb.teichmann at gmail.com> wrote: > 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. > > While this all is in the making, PJ could monkey-patch __build_class__ > to do the steps described above, until it gets accepted into cpython. > So I pose the question to PJ: would such an approach solve the > problems you have? Universal member post-processing actually works *better* for the motivating use case than the metaclass or class level hooks, so yes. In practice, there is one potential hiccup, and that's that decorators which aren't aware of __post_process__ will end up masking it. But that's not an insurmountable obstacle.
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