Re: [Python-Dev] PEP487: Simpler customization of class creation

Hi - sorry for steppign in late - I've just reread the PEP and tried out the reference implementation, and I have two sugestions/issues with it as is: 1) Why does `__init_subclass__` is not run in the class it is defined itself?? That makes no sense to me as in very unpythonic. I applied the patch at issue, 27366 went to the terminal, and created a "hello world" __init_subclass__ with a simple print statement, and was greatly surprised that it did not printout. Only upon reviewing the PEP text I inferred that it was supposed to work (as it did) in further subclasses of my initial class. After all, issubclass(A, A) is usually True. I pledge for this behavior to be changed on the PEP. If one does not want it to run on the baseclass, a simple default argument and an `if param is None: return` on the method body can do the job, with less exceptions and surprises. Otherwise, I'd suggest at least some PEP rewording to make explicit the fact it is not run on the class it is defined at all. (I can help with that, but I'd rather see it implemented as above). I can see the fact that it woudl have little effect, as any eventual parameter on the Base class could be hardcoded into the class body itself - but just imagine a class hierarchy with cooperative "__init_subclass__" methods - it would be rather surprising that each class has to count on its parents __init_subclass__ being run, without the one defined in its own body being called - that is rather surprising. ------- 2) I have another higher level concern with the PEP as well: It will pass all class keyword parameters, but for "metaclass" to "__init_subclass__" - thus making it all but impossible to any other keyword to the class creation machinery to ever be defined again. We can't think of any such other keyword now, but what might come in a couple of years? What about just denoting in the PEP that "double under" keywords should be reserved and not relied to not be used by "type" itself in the future? (or any other way of marking reserved class kewyords) - actually it would even make sense to make "__metaclass__" an alias for "metaclass" in the class creation machinery. Anyway the PEP itself should mention that currently the keyword-arg "metaclass" is swallowed by the class creation machinery and will never reach `__init_subclass__` - this behavior is less surprising for me, but it should be documented) Or, an even less exceptional behavior for the future: make it so that "metaclass" specifies a custom metaclass (due to compatibility issues) AND is passed to __init_subclass__, and "__metaclass__" specifies a metaclass and is not passed (along with other double-unders as they are defined)). (as an extra bonus, people migrating from Python 2 to Python 3.6 will not even be surprised by the keyword argument being __metaclass__) Best regards, js -><- On 25 July 2016 at 00:49, Nick Coghlan wrote:

On 25 July 2016 at 03:00, Guido van Rossum wrote:

...

Yes.

OK, we can cover that in the documentation - if folks want to emulate what happens during class construction after the fact, they'll need to do:

cls.name = attr attr.__set_name__(cls, "name")

Semantically, I agree that approach makes sense - by default, descriptors created outside a class body won't have a defined owning class or attribute name, and if you want to give them one, you'll have to do it explicitly.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@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/jsbueno%40python.org.br