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 | ncogh...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
On 28 July 2016 at 03:56, Joao S. O. Bueno wrote: > 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). This is covered in the PEP: https://www.python.org/dev/peps/pep-0487/#calling-the-hook-on-the-class-itself > 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? This isn't a new problem, as it already exists today for custom metaclasses. It just means introducing new class construction keywords at the language level is something that needs to be handled judiciously, and with a view to the fact that it might have knock-on effects for other APIs which need to find a new parameter name. Regards, Nick. -- Nick Coghlan | ncogh...@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/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
On 27 July 2016 at 22:30, Nick Coghlan wrote:
> On 28 July 2016 at 03:56, Joao S. O. Bueno wrote:
>> 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).
>
> This is covered in the PEP:
> https://www.python.org/dev/peps/pep-0487/#calling-the-hook-on-the-class-itself
>
>> 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?
>
> This isn't a new problem, as it already exists today for custom
> metaclasses. It just means introducing new class construction keywords
> at the language level is something that needs to be handled
> judiciously, and with a view to the fact that it might have knock-on
> effects for other APIs which need to find a new parameter name.
>
Actually, as documented on the PEP (and I just confirmed at a Python
3.5 prompt),
you actually can't use custom keywords for class defintions. This PEP
fixes that, but at the same time makes any other class reserved
keyword impossible in the future - that is, unless a single line
warning against reserved name patterns is added. I think it is low a
cost not to be paid now, blocking too many - yet to be imagined -
future possibilities.
(as for the example in Py 3.5):
In [17]: def M(type):
...: def __new__(metacls, name, bases, dict, **kw):
...: print(kw)
...: return super().__new__(name, bases, dict)
...: def __init__(cls, name, bases, dict, **kw):
...: print("init...", kw)
...: return super().__init__(name, bases, dict)
...:
In [18]: class A(metaclass=M, test=23, color="blue"):
...: pass
...:
---
TypeError Traceback (most recent call last)
in ()
> 1 class A(metaclass=M, test=23, color="blue"):
2 pass
TypeError: M() got an unexpected keyword argument 'color'
> Regards,
> Nick.
>
> --
> Nick Coghlan | ncogh...@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/archive%40mail-archive.com
