question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

order in dict is not preserved

See original GitHub issue

Python 3.6.3 import yaml document = """ b: c: 3 d: 4 a: 1 """ print(yaml.dump(yaml.load(document), default_flow_style=False)) a: 1 b: c: 3 d: 4

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:32
  • Comments:34 (8 by maintainers)

github_iconTop GitHub Comments

61reactions
sigmavirus24commented, Dec 12, 2017

This is a property of Python, not PyYAML. Python does not preserve the order of dictionaries and so we cannot either. To do so, you’d have to yaml.load into an OrderedDict (a dictionary implementation that preserves order). Cheers!

58reactions
shooglecommented, May 26, 2018

the yaml-specs do not guarantee an order.

Correct.

As PyYAML is a yaml parser, guaranteeing order seems like a slight breach of the yaml specs.

Wrong. Since the spec doesn’t guarantee an order, that means any order is valid. PyYAML could return dict keys in any arbitrary order (alphabetical, reverse-alphabetical, shortest first, random, order of creation, etc.) and it would still be perfectly consistent with the YAML specification.

In practice, the only ordering that makes any sense is the order in which they were created, because if they are returned in a different order then the information about which was created first is lost forever. If the user requires any other form of ordering (alphabetical, etc.), then he/she is able to sort the dict themself after it has been returned in creation order. However, if the dict is not returned in creation order then the user can never put it back in creation order (except by a lucky guess).

It is for this very reason that, since Python 3.7, dictionaries are ordered by default as a feature of the language (and not just as an implementation detail as they were in 3.6).

This is why I think returning in creation order should be the default in PyYAML (at least for Python >= 3.7) and not just an option, though I understand the desire to ensure backwards compatibility. (It should be noted, however, that nobody complained when Python dicts became ordered by default, even though it could be seen as a backwards-incompatible change.)

Read more comments on GitHub >

github_iconTop Results From Across the Web

Python Dictionaries Are Now Ordered. Keep Using OrderedDict.
Until recently, Python dictionaries did not preserve the order in which items were added to them. For instance, you might type {'fruits': ...
Read more >
python - How to keep keys/values in same order as declared?
python dictionaries are unordered. If you want an ordered dictionary, try collections.OrderedDict. Note that OrderedDict was introduced into the standard ...
Read more >
Dictionaries preserve ordering - Python Insight
Actually, no. The thing with an OrderedDict is that ordering is assumed to have meaning over and above the values stored.
Read more >
OrderedDict vs dict in Python: The Right Tool for the Job
Python's OrderedDict is a dict subclass that preserves the order in which key-value pairs, commonly known as items, are inserted into the dictionary....
Read more >
Dicts are now ordered, get used to it - Ivan Sagalaev
Python has had ordered dicts for a long time (in "containers.ordereddict" I think). The change described above, in Python 3.6 (from 2016) merely ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found