I’ve pushed a minor update to the PEP to the repository. The benchmark results are still out of date, I need want to run those on an idle machine to get reliable results.
The PEP has one significant change w.r.t. the previous version: it now requires the use of a new type flag to enable the usage of the new slot in C code. This is due to concerns that loading old extensions might crash the interpreter otherwise. References to earlier discussions (also added to the PEP): * http://marc.info/?l=python-dev&m=137510220928964&w=2 * https://mail.python.org/pipermail/python-ideas/2014-July/028420.html * https://mail.python.org/pipermail/python-dev/2013-July/127321.html And finally, I’ve updated the implementation in issue 18181. The implementation passes the test suite with the current trunk and is good enough to play around with. There is still an important issue though: I’ve done some micro benchmarking and those indicate that the method_cache mechanism in typeobject.c doesn’t work with my changes and that has a clear performance impact and must be fixed. That shouldn’t be too hard to fix, it’s probably just a botched check before the blocks of code that use and update the cache. Ronald > On 24 Jul 2015, at 19:55, Ronald Oussoren <ronaldousso...@mac.com> wrote: > >> >> On 24 Jul 2015, at 17:29, Nick Coghlan <ncogh...@gmail.com >> <mailto:ncogh...@gmail.com>> wrote: >> >> On 25 July 2015 at 00:50, Brett Cannon <br...@python.org >> <mailto:br...@python.org>> wrote: >>> Leave the decorator out like __new__, otherwise people are bound to forget >>> it and have a hard time debugging why their code doesn't work. >> >> I'd actually advocate for keeping this as a metaclass method, rather >> than making it available to any type instance. The key thing to >> consider for me is "What additional power does making it a method on >> the class itself grant to mixin types?” > > To be honest, I hadn’t considered mixin types yet. > >> >> With PEP 487, the __init_subclass__ proposal only grants mixins the >> power to implicitly run additional code when new subclasses are >> defined. They have no additional ability to influence the behaviour of >> the specific class adding the mixin into the inheritance hierarchy. >> >> With PEP 447, as currently written, a mixin that wants to alter how >> descriptors are looked up will be able to do so implicitly as long as >> there are no other custom metaclasses in the picture. As soon as there >> are *two* custom metaclasses involved, you'll get an error at >> definition time and have to sort out how you want the metaclass >> inheritance to work and have a chance to notice if there are two >> competing __getdescriptor__ implementations. >> >> However, if __getdescriptor__ moves to being a class method on object >> rather than an instance method on type, then you'll lose that >> assistance from the metaclass checker - if you have two classes in >> your MRO with mutually incompatible __getdescriptor__ implementations, >> you're likely to be in for a world of pain as you try to figure out >> the source of any related bugs. > > That’s a good point, and something that will move something that I’ve > wanted to look into forward on my list: the difference between a > classmethod and a method on the class defined through a metaclass. > > The semantics I’d like to have is that __getdescriptor__ is a local decision, > defining __getdescriptor__ for a class should only affect that class and its > subclass, and shouldn’t affect how superclasses are handled by > __getattribute__. > That is something that can be done by defining __getdescriptor__ on a > metaclass, > and AFAIK requires active cooperation when using a @classmethod. > > It should be possible to demonstrate the differences in a pure Python > prototype. > > Ronald > >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncogh...@gmail.com <mailto:ncogh...@gmail.com> | >> Brisbane, Australia >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org <mailto:Python-Dev@python.org> >> https://mail.python.org/mailman/listinfo/python-dev >> <https://mail.python.org/mailman/listinfo/python-dev> >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com >> <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
_______________________________________________ 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
