OrderedDicts do not guarantee ordering on decode

[chiefnoah]

When decoding a map that was encoded as an OrderedDict, the resulting map is a standard python dict which does not guarantee ordering. I don't believe ordered maps are part of RFC 7049, but it may make sense to simply always return an OrderedDict (maybe as a flag on CBORDecoder init) instead of dict given that they should be always be decoded in the order they were encoded in.

[Sekenre]

What's even worse is that "Canonical" encoding requires that CBOR map keys be in a specific order.

I think for cross language interoperability OrderedDict should always be encoded as a tagged sequence with an even number of elements. This will ensure that order is preserved across implementations.

[Sekenre]

I wrote up a proposal that we grab tag 272 for this:
https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md

[xmo-odoo]

When decoding a map that was encoded as an OrderedDict, the resulting map is a standard python dict which does not guarantee ordering.

Python dicts have formally guaranteed ordering since 3.7 (released 2018) and informally since 3.6 (released 2015). 3.6 and older are long out of any support, even 3.7 only gets security support until the end of the month (2023-06-27). As long as the entries are encoded in-order and cbor2 then rehydrates the dict in that order, the resulting dict will preserve the original ordering.

Then again, cbor itself does not guarantee the ordering preservation of maps, and lots of languages don't maintain ordering of the default map type (some going as far as to intentionally scramble it).

[chiefnoah]

When I opened this I was stuck on Python 3.5 due to a large dependency that was very opinionated about Python version. That's now since been resolved. Regardless, the semantic difference between an ordered and unordered map is important, largely for other languages where the map implementation may or may not choose to preserve ordering information.