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

[Nick Coghlan]

On 2 April 2015 at 07:35, PJ Eby <pje at telecommunity.com> wrote:
> I recently got an inquiry from some of my users about porting some of
> my libraries to Python 3 that make use of the Python 2 __metaclass__
> facility.  While checking up on the status of PEP 422 today, I found
> out about its recently proposed replacement, PEP 487.
>
> While PEP 487 is a generally fine PEP, it actually *rules out* the
> specific use case that I wanted PEP 422 for in the first place:
> dynamic addition of callbacks or decorators for use at class creation
> time without requiring explicit inheritance or metaclass
> participation.  (So that e.g. method decorators can access the
> enclosing class at class definition time.)

How hard is the requirement against relying on a mixin class or class
decorator to request the defining class aware method decorator
support? Is the main concern with the fact that failing to apply the
right decorator/mixin at the class level becomes a potentially silent
failure where the class aware method decorators aren't invoked
properly?

> So...  honestly, I'm not sure where to go from here.  Is there any
> chance that this is going to be changed, or revert to the PEP 422
> approach, or...  something?  If so, what Python version will the
> "something" be in?  Or is this use case just going to be a dead parrot
> in Python 3, period?

My preference at this point would definitely be to introduce a mixin
class into the affected libraries and frameworks with an appropriate
PEP 487 style __init_subclass__ that was a noop in Python 2 (which
would rely on metaclass injection instead), but implemented the
necessary "defining class aware" method decorator support in Python 3.

The question of dynamically injecting additional base classes from the
class body to allow the use of certain method decorators to imply
specific class level behaviour could then be addressed as a separate
proposal (e.g. making the case for an "__append_mixins__" attribute),
rather than being linked directly to the question of how we going
about defining inherited creation time behaviour without needing a
custom metaclass.

Regards,
Nick.

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