On Wed, Dec 30, 2020, 1:05 AM Guido van Rossum <gu...@python.org> wrote:
> I need to think about this more. > > Technically the class *is* created at the point `__init_subclass__` is > called. What the metaclass does after that point is embellishment. > > Most metaclasses will have sufficient control for their needs because they > can manipulate the contents of the namespace that's passed to type_new() -- > I understand that doesn't work for Enum because the instances have a > reference to the class in them. > > I suspect the classes that you claim are "buggy" are fine in practice, > even if you can construct a counterexample. > > All in all I just worry about the backward compatibility here: one could > easily imagine a metaclass whose `__new__` relies on the effect of the > `__init_subclass__` called by type_new(), and moving the call would break > that. So it's probably 6 bugs fixed, half a dozen new bugs created. In such > a case, the status quo should win. > I admit I don't know anything about the metaclass internals, but if backward compatibility is an issue, couldn't we create a new dunder instead of moving the existing one? Say, call it __init_subclass_2__ (and bikeshed the name later), and document that as being called at the point to which it's currently proposed to move the calling of __init_subclass__. With that, there is zero breakage of existing code, and code that can benefit from the new behavior simply uses a different dunder. __init_subclass__ could potentially be deprecated in the future if it's determined that it has no benefit over the new dunder, but doesn't need to deprecated immediately. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VWNYDERWSPE7MIN2TVRSFM6AM7RLF6AO/ Code of Conduct: http://python.org/psf/codeofconduct/
