On Sun, Feb 10, 2013 at 10:47 PM, Antoine Pitrou email@example.com wrote:
On Sun, 10 Feb 2013 22:32:50 +1000 Nick Coghlan firstname.lastname@example.org wrote:
Replaces many use cases for dynamic setting of ``__metaclass__``
For use cases that don't involve completely replacing the defined class, Python 2 code that dynamically set ``__metaclass__`` can now dynamically set ``__init_class__`` instead. For more advanced use cases, introduction of an explicit metaclass (possibly made available as a required base class) will still be necessary in order to support Python 3.
At least PEAK uses it for interface declarations, I believe Zope do something similar.
However, just as I championed PEP 414 to make porting Unicode-aware projects easier, I'm championing this one because I don't consider it acceptable for Python 3 to be a less capable language than Python 2 in this regard. Having come up with what I consider to be an elegant design to restore that capability, I'm not especially interested in passing judgment on the worthiness of what PJE is doing with Python 2 metaclasses that cannot currently be replicated in Python 3.
So, what are the use cases? I probably write metaclasses once a year, I wonder how much incentive there is to bring an additional complication to the already complicated class construction process.
One of the main goals of the PEP is actually to give people even *less* reason to write custom metaclasses, as you won't need to write one any more if all you want to do is adjust the class attributes after execution of the class body completes, and automatically do the same for any subclasses. (The latter part is key - if you don't want inheritance, then class decorators fill the role just fine. That's why the design in the PEP is the way it us - __init_class__ effectively becomes the innermost class decorator, which is called even for subclasses)