Suppose you want to make something like an XML generator helper function:
def start(tag_, **kwargs):
write("<" + escape(tag_))
if kwargs:
for k, v in kwargs.item():
write(" " + escape(k) + "=" + quote_escape(v))
write(">")
(Apply hand-wavying to get the correct code.) This might be called as:
start("abc", x="1.0", y="2.0")
but generate the output
<abc y="2.0" x="1.0">
when you want it to be:
<abc x="1.0" y="2.0">
The output order depends on the Python hash implementation, which (in modern Pythons) is randomly selected during startup. For an API which preserves order, you must currently either pass in the pairs in iterable order, like:
start("abc", (("x", "1.0"), ("y", "2.0")))
or switch the API to pass in a dictionary-like object instead of kwargs, then switch to an OrderedDict (which must also be initialized with pairs in iterable order).
In 3.6, there's no need for that -- kwargs will preserve the keyword parameter order.
They are equivalent. That doesn't mean that all tools will use XML semantics to test for equivalence.
A testing tool might require that the output is byte-for-byte equivalent to a known good output. Python's pseudorandomly determined hash function won't preserve that order across multiple runs.
XML itself doesn't no, humans may, and some crappy crummy tools sadly do as well[0].
Round-tripping ordering is also convenient for automated processing tools as well (e.g. add/remove parameters without introducing extraneous unnecessary changes)
[0] some also do care about namespace aliases/prefixes, which is a bit of a shock the first time they choke on your perfectly valid and namespaced XML.
This is why it will be defacto stabilized quickly (because it's so useful).
I'm sure the python developers have considered that, since they explicitly chose to preserve order instead of other small non-order preserving optimizations that could have been done with the new representation.
I don't quite get it though.