On 14 June 2016 at 02:41, Nikita Nemkin <nik...@nemkin.ru> wrote: > Is there any rationale for rejecting alternatives like:
Good questions - Eric, it's likely worth capturing answers to these in the PEP for the benefit of future readers. > 1. Adding standard metaclass with ordered namespace. Adding metaclasses to an existing class can break compatibility with third party subclasses, so making it possible for people to avoid that while still gaining the ability to implicitly expose attribute ordering to class decorators and other potentially interested parties is a recurring theme behind this PEP and also PEPs 422 and 487. > 2. Adding `namespace` or `ordered` args to the default metaclass. See below (as it relates to your own complexity argument) > 3. Making compiler fill in __definition_order__ for every class > (just like __qualname__) without touching the runtime. > ? Class scopes support conditionals and loops, so we can't necessarily be sure what names will be assigned without running the code. It's also possible to make attribute assignments via locals() that are entirely opaque to the compiler, but visible to the interpreter at runtime. > To me, any of the above seems preferred to complicating > the core part of the language forever. > > The vast majority of Python classes don't care about their member > order, this is minority use case receiving majority treatment. > > Also, wiring OrderedDict into class creation means elevating it > from a peripheral utility to indispensable built-in type. Right, that's one of the key reasons this is a PEP, rather than just an item on the issue tracker. The rationale for "Why not make this configurable, rather than switching it unilaterally?" is that it's actually *simpler* overall to just make it the default - we can then change the documentation to say "class bodies are evaluated in a collections.OrderedDict instance by default" and record the consequences of that, rather than having to document yet another class customisation mechanism. It also eliminates boilerplate from class decorator usage instructions, where people have to write "to use this class decorator, you must also specify 'namespace=collections.OrderedDict' in your class header" Folks that don't need the ordering information do end up paying a slight import time and memory cost, which is another key reason for handling the proposal as a PEP rather than just as a tracker issue. Aside from the boilerplate reduction when used in conjunction with a class decorator, a further possible category of consumers would be documentation generators like pydoc and Sphinx apidoc, which may be able to switch to displaying methods in definition order, rather than the current approach of always listing them in alphabetical order. 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/archive%40mail-archive.com
