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

[Joao S. O. Bueno]

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 <ncoghlan at gmail.com> wrote:
> On 25 July 2016 at 03:00, Guido van Rossum <gvanrossum at gmail.com> 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 at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br