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

[Ethan Furman]

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~