RetroSearch Browse

Thu Apr 2 10:46:11 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-April/138977.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-April/138977.html below:

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