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

Ethan Furman ethan at stoneleaf.us
Thu Apr 2 18:33:42 CEST 2015

On Thu, Apr 02, 2015 at 06:46:11PM +1000, Nick Coghlan wrote:

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.

Perhaps PEP 422 should be back in the running then (possible reduced in scope, I haven't read it in a while), along with PEP 487, since they seem to target different areas.

-- Ethan

More information about the Python-Dev mailing list