3 ms·

> Python chooses to provide (3) because Python is slow anyway so why not at least provide the least surprising container given how slow the language is. The exi

> Python chooses to provide (3) because Python is slow anyway so why not at least provide the least surprising container given how slow the language is. The existing Python dict was so awful that OrderedDict is actually faster (not fast in the wider scheme of things, but faster than that) so that's good enough. That is completely incorrect. The builtin dict is similar to https://docs.rs/indexmap/latest/indexmap/ https://docs.rs/indexmap/latest/indexmap/ not a linked hashmap, it was used because it significantly improves iteration speed and uses less memory.

tialaramex 2y ago
The crucial thing about IndexedMap is that it is not actually order preserving. If it gets inconvenient to preserve order, it's just not preserved. For example if I put sixty items in, then remove thirty and add forty more, IndexedMap doesn't put all those forty items "after" the remaining thirty from the removal because that's more work. Python does preserve order, the fact that internally it looks somewhat like IndexedMap is an implementation detail.
- masklinn 2y ago
  > the fact that internally it looks somewhat like IndexedMap is an implementation detail. It really is not. IndexMap was directly inspired by Python’s naturally ordered dicts. It’s spelled out right in the readme. And while indexmap has weaker ordering guarantees for performance reasons (though also additional features aplenty), “ordermap” was revived as a wrapper which does conserve ordering on removal.
assbuttbuttass 2y ago
The downside of something like indexmap is now removal is O(n)
- masklinn 2y ago
  If you do the remove naively yes, but you can use tombstoning which amortises the cost (at that of an increased iteration overhead), or using a non-order-preserving remove (like indexmap itself, though `remove` has been deprecated and you now get to pick your poison).

tialaramex 2y ago

The crucial thing about IndexedMap is that it is not actually order preserving. If it gets inconvenient to preserve order, it's just not preserved. For example if I put sixty items in, then remove thirty and add forty more, IndexedMap doesn't put all those forty items "after" the remaining thirty from the removal because that's more work. Python does preserve order, the fact that internally it looks somewhat like IndexedMap is an implementation detail.

masklinn 2y ago
> the fact that internally it looks somewhat like IndexedMap is an implementation detail. It really is not. IndexMap was directly inspired by Python’s naturally ordered dicts. It’s spelled out right in the readme. And while indexmap has weaker ordering guarantees for performance reasons (though also additional features aplenty), “ordermap” was revived as a wrapper which does conserve ordering on removal.

assbuttbuttass 2y ago

The downside of something like indexmap is now removal is O(n)

masklinn 2y ago
If you do the remove naively yes, but you can use tombstoning which amortises the cost (at that of an increased iteration overhead), or using a non-order-preserving remove (like indexmap itself, though `remove` has been deprecated and you now get to pick your poison).