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. 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
