[Python-Dev] PEP487: Simpler customization of class creation
Joao S. O. Bueno
jsbueno at python.org.br
Thu Jul 28 09:12:49 EDT 2016
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
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?
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev