Comment by orf
Try not to throw around statements like “they broke duct ordering because they felt like it”.
Obviously they didn’t do that. There are trade-offs when preserving dictionary ordering.
Try not to throw around statements like “they broke duct ordering because they felt like it”.
Obviously they didn’t do that. There are trade-offs when preserving dictionary ordering.
I get that all dicts are now effectively an `collections.OrderedDict`, but I've never seen practical code that uses the insertion order. You can't do much with that info (no `.pop()`, can't sort a dict without recreating it) beyond maybe helping readability when you print or serialize it.
if you claim
> high-performance Python implementation
then no this aren't trade-offs but breaking the standard without it truly being necessary
most important this will break code in a subtle and potentially very surprising way
they could just claim they are python like and then no one would hold them for not keeping to the standard
but if you are misleading about your product people will find offense even if it isn't intentionally
This might be what you meant, but the ordered dicts are faster, no? I believe ordering was initially an implementation detail that arose as part of performance optimisations, and only later declared officially part of the spec.
> but the ordered dicts are faster, no?
They may be in the current implementations, but removing an implementation constraint can only increase the solution space, so it cannot make the best implementation slower.
As a trivial example, the current implementation that guarantees iteration happens in insertion order also is a valid implementation for a spec that does not require that guarantee.
dicts ordering keys in insertion order isn't an implementation detail anymore and hasn't been for years.