On 25 July 2015 at 00:50, Brett Cannon <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?" 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
