On Thu, Apr 02, 2015 at 06:46:11PM +1000, Nick Coghlan wrote: > On 2 April 2015 at 16:38, PJ Eby <p...@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~ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
