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

Nick Coghlan ncoghlan at gmail.com
Thu Apr 2 10:46:11 CEST 2015

On 2 April 2015 at 16:38, PJ Eby <pje at telecommunity.com> wrote:

IOW, there's no need to modify the core just to have that feature, since if you control the base class you can already do what PEP 487 does in essentially every version of Python, ever. If that's all PEP 487 is going to do, it should just be a PyPI package on a stdlib-inclusion track, not a change to core Python. It's not actually adding back any of the dynamicness (dynamicity? hookability?) that PEP 3115 took away.

The specific feature that PEP 487 is adding is the ability to customise creation of subclasses without risking the introduction of a metaclass conflict. That allows it to be used in situations where adopting any of the existing metaclass based mechanisms would require a potential compatibility break (as well as being far more approachable as a mechanism than the use of custom metaclasses).

The gap I agree this approach leaves is a final post-namespace-execution step that supports establishing any class level invariants implied by decorators and other functions used in the class body. Python 2 allowed that to be handled with a dynamically generated metaclass and PEP 422 through autodecorate, while PEP 487 currently has no equivalent mechanism.

Regards, Nick.

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

More information about the Python-Dev mailing list