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

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 __build_class__ 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