[Python-Dev] PEP 487 vs 422 (dynamic class decoration) (original) (raw)
PJ Eby pje at telecommunity.com
Fri Apr 3 18:02:28 CEST 2015
- Previous message (by thread): [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
- Next message (by thread): [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 postprocess 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 buildclass 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.
- Previous message (by thread): [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
- Next message (by thread): [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]