4 ms·

"Ordered dict" is ambiguous, and from the title I thought that key order was meant. Reading the article, I see that it's actually insertion order. Which makes m

"Ordered dict" is ambiguous, and from the title I thought that key order was meant. Reading the article, I see that it's actually insertion order. Which makes much more sense. Key order would have been a much more significant change.

_verandaguy 7y ago
Not to mention there's often no meaningful way to order by key value since keys can be any hashable values -- so things like this break this idea: _dict = {} _dict.update({MyObject: 3}) _dict.update({'MyObject': 3}) There's no ordering over _most_ hashable values since they span multiple types, so insertion ordering is the only sane way to do it.
- Sharlin 7y ago
  Well, keys of sorted dictionaries don’t need to be hashable but do need an ordering, whether intrinsic or user-provided. A sorted map (usually implemented in terms of a binary search tree) is simply a separate data type with different requirements than a hash table based one.
- masklinn 7y ago
  A sorted map would be tree-based and require its keys to be orderable but not hashable. For instance Rust's HashMap has its key bound on Hash + Eq, while BTreeMap's is bound on Ord. They're different data structures, with different use cases and different requirements. > There's no ordering over _most_ hashable values since they span multiple types, so insertion ordering is the only sane way to do it. Python 2 actually had total ordering of all values. The result was usually stupid but it was there.
  - _verandaguy 7y ago
    >The result was usually stupid but it was there This is what I meant by "sane" in my comment. It's _way_ more meaningful to the user if data's insertion-ordered.
jiveturkey 7y ago
It's not ambiguous, because it refers to the long pre-existing OrderedDict class.
- geophile 7y ago
  Yes, I see that, but the title is unclear.
masklinn 7y ago
> I thought that key order was meant. Surely that would be a sorted dict not an ordered dict.

_verandaguy 7y ago

Not to mention there's often no meaningful way to order by key value since keys can be any hashable values -- so things like this break this idea: _dict = {} _dict.update({MyObject: 3}) _dict.update({'MyObject': 3}) There's no ordering over _most_ hashable values since they span multiple types, so insertion ordering is the only sane way to do it.

Sharlin 7y ago
Well, keys of sorted dictionaries don’t need to be hashable but do need an ordering, whether intrinsic or user-provided. A sorted map (usually implemented in terms of a binary search tree) is simply a separate data type with different requirements than a hash table based one.
masklinn 7y ago
A sorted map would be tree-based and require its keys to be orderable but not hashable. For instance Rust's HashMap has its key bound on Hash + Eq, while BTreeMap's is bound on Ord. They're different data structures, with different use cases and different requirements. > There's no ordering over _most_ hashable values since they span multiple types, so insertion ordering is the only sane way to do it. Python 2 actually had total ordering of all values. The result was usually stupid but it was there.
- _verandaguy 7y ago
  >The result was usually stupid but it was there This is what I meant by "sane" in my comment. It's _way_ more meaningful to the user if data's insertion-ordered.

jiveturkey 7y ago

It's not ambiguous, because it refers to the long pre-existing OrderedDict class.

geophile 7y ago
Yes, I see that, but the title is unclear.

masklinn 7y ago

> I thought that key order was meant. Surely that would be a sorted dict not an ordered dict.