On 28 July 2016 at 04:26, Nick Coghlan <ncogh...@gmail.com> wrote: > On 28 July 2016 at 13:55, Joao S. O. Bueno <jsbu...@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 | 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
