[Python-Dev] PEP 487 vs 422 (dynamic class decoration) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Fri Apr 3 10:26:50 CEST 2015

On 3 April 2015 at 18:21, Nick Coghlan <ncoghlan at gmail.com> wrote:

That means I'm now OK with monkeypatching buildclass being the only way to get dynamic hooking of the class currently being defined from the class body - folks that really want that behaviour can monkeypatch it in, while folks that think it's a bad idea don't need to worry about.

[snip]

PEP 422 has never been approved - it's only ever been Draft or Deferred (and now Withdrawn). If you would like to take it over and champion it as a competitor to PEP 487, I'd be fine with that, I just no longer think it's a good idea myself.

[snip]

Given my change of heart, I believe that at this point, if you were willing to champion a revived PEP 422 that implemented the behaviour you're after, that would be ideal, with monkeypatching the desired behaviour in as a fallback plan if the PEP is still ultimately rejected. Alternatively, you could go the monkeypatching path first, and then potentially seek standardisation later after you've had some practical experience with it - I now consider it an orthogonal capability to the feature in PEP 487, so the acceptance of the latter wouldn't necessarily preclude acceptance of a hook for class postprocessing injection.

Heh, editing fail. Writing out this post in full made me realise the last of these options was a potentially reasonable path forward, but I didn't go back and correct the earlier sections where I was viewing the situation differently. So if the post reads a self-contradictory, that's because it is, but the last one is the one that best reflects my current thinking :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list