On Sun, 10 Feb 2013 23:17:00 +1000 Nick Coghlan firstname.lastname@example.org wrote:
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.
zope.interface has been ported to Python 3, so the annoyance can't be very blocking.
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.
This sounds like a theoretical concern rather than a practical one.
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.
It may be locally elegant, but it still brings additional complication to the global model. Reading your proposal reminds me of the various ways of influencing the pickle protocol: http://docs.python.org/dev/library/pickle.html#pickling-class-instances
Nobody can claim this is simple and easy to wrap your head around. It is a maintenance burden, and it discourages understanding of the underlying model by anyone but language experts.