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

[Joao S. O. Bueno]

On 28 July 2016 at 04:26, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 28 July 2016 at 13:55, Joao S. O. Bueno <jsbueno at python.org.br> wrote:
>> 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.
>
> We don't warn against people defining new dunder-protocols as methods,
> why would we warn against a similar breach of convention in this case?
> I'm also wondering how you would want such a warning to work if we
> ever claimed a parameter name for a base class in the standard
> library, but didn't claim it as a name supported by type/object.
>
> Note that I'm not denying that it *may* be annoying *if* we define a
> new universal class parameter at some point in the future *and* it
> collides with a custom parameter in a pre-existing API *and* the
> authors of that API miss the related PEP.
>
> However, given that we've come up with exactly one named class
> parameter to date (metaclass), and explicitly decided against adding
> another (namespace, replaced with PEP 520's simpler option of just
> making the standard namespace provide attribute ordering data), the
> odds of actually encountering the posited problematic scenario seem
> pretty remote.

That is alright.
(Even though, I think somewhere around there are remarks against one
putting forth his own dunder methods) .

But that elaves another issue open: the "metaclass" parameter get in
to a very odd position, in which it has nothing distinctive about it,
still is the only parameter that will be swallowed and won't reach
"__init_subclass__".

 Although I know it is not straightforward to implement (as the
"metaclass" parameter is not passed to the metaclass __new__ or
__init__), wouldn't it make sense to make it be passed to
__init_subclass__ just like all other keywords?  (the default
__init_subclass__ then could swallow it, if it reaches there).


I am putting the question now, because it is a matter of "now" or
"never" - I can see it can does make sense if it is not passed down.

Anyway, do you have any remarks on the first issue I raised? About
__init_subclass__ being called in the class it is defined in, not just
on it's descendant subclasses?


>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia