[Python-Dev] PEP520 and absence of definition_order (original) (raw)

Russell Keith-Magee russell at keith-magee.com
Sun Sep 11 00:15:36 EDT 2016

On Sun, Sep 11, 2016 at 11:05 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 11 September 2016 at 07:26, Guido van Rossum <guido at python.org> wrote: > On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: >> On 11 September 2016 at 03:08, Guido van Rossum <guido at python.org> wrote: >>> So I'm happy to continue thinking about this, but I expect this is not >>> such a big deal as you fear. Anyway, let's see if someone comes up >>> with a more convincing argument by beta 2! >> >> For CPython specifically, I don't have anything more convincing than >> Ethan's Enum example (where the way the metaclass works means most of >> the interesting attributes don't live directly in the class dict, they >> live in private data structures stored in the class dict, making >> "list(MyEnum.dict)" inherently uninteresting, regardless of >> whether it's ordered or not). > > But that would only matter if we also defined a helper utility that > used definitionorder. I expect that the implementation of Enum > could be simplified somewhat in Python 3.6 since it can trust that the > namespace passed into new is ordered (so it doesn't have to switch > it to an OrderedDict in prepare, perhaps). > > In any case the most likely way to use definitionorder in general > was always to filter its contents through some other condition (e.g. > "isn't a method and doesn't start with underscore") -- you can do the > same with keys(). Classes that want to provide a custom list of > "interesting" attributes can provide that using whatever class method > or attribute they want -- it's just easier to keep those attributes > ordered because the namespace is always ordered.

For example,it's already possible to expose order information via dir, consumers of the information just have to bypass the implicit sorting applied by the dir() builtin: >>> class Example: ... def dir(self): ... return "first second third fourth".split() ... >>> dir(Example()) ['first', 'fourth', 'second', 'third'] >>> Example().dir() ['first', 'second', 'third', 'fourth'] You've persuaded me that omitting definitionorder is the right thing to do for now, so the last thing I'm going to do is to explicitly double check with the creators of a few interesting alternate implementations (MicroPython, VOC for JVM environments, Batavia for JavaScript environments) to see if this may cause them problems in officially implementing 3.6 (we know PyPy will be OK, since they did it first). VOC & Batavia should be OK (worst case, they return collections.OrderedDict from prepare and also use it for dict attributes), but I'm less certain about MicroPython (since I don't know enough about how its current dict implementation works to know whether or not they'll be able to make the same change PyPy and CPython did)

From the perspective of VOC and Batavia: As Nick notes, there may be some changes needed to use OrderDict (or a native analog) in a couple of places, but other than that, it doesn’t strike me as a change that will pose any significant difficulty.

Yours, Russ Magee %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160911/7cde00e5/attachment.html>

More information about the Python-Dev mailing list