Live data from Hacker News

Python dicts are now ordered

softwaremaniacs.org

51–60 of 457 posts

Re: Python dicts are now ordered

#51
post #39
post #36

Earlier quoted context omitted.

You're right, I read the gp too quickly. But in the case of downgrading, I'm fairly sure there's a number of other breaking changes that can't trivially downgrade minor versions. Like f-strings were only introduced in python3.6 as I recall. Async keyword only exists as of 3.4 as well I think?

Introducing things is different than changing things.

Sure, but you can't safely take everything from a higher version to a lower version in any case; if insertion order became gauranteed due to a bugfix, and wasn't backported, you'd be in the same boat.

The only way to consistently code cross-version is to start with the lowest you plan to support (assuming the higher versions are actually backwards-compatible).

Does any language gaurantee that code is both backwards and forwards compatible?

Re: Python dicts are now ordered

#52

Earlier quoted context omitted.

It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python

If you know you're supporting old code, use OrderedDict. you arguably ought to anyway, for explicitness.

right, so making it implicit is bad design

Re: Python dicts are now ordered

#53
post #33

Earlier quoted context omitted.

These collections are often default defined as unordered collections; it’s just that people discovered over time that some were iterable even if the language docs said otherwise.

I don't think ordering and iteration are related, are they? Whether something is sortable has no impact on whether it is enumerable.

What would it even mean for a container to be ordered if you can't iterate through it?

Re: Python dicts are now ordered

#56
post #15

Am I the only one that thinks this is a stupid decision? This will silently break code that starts to rely on this behaviour that gets executed on Python3.5 and lower. I would consider changing how a builtin works to be a major breaking change. It would have been fine if this was a change between 2 and 3 but on a minor version? Thats insane.

I don't see exactly how one would rely on dicts not being sorted, as it was already answered by another comments.

And beyond this, even if maintaining backward compatibility is important, I don't think it should prevent software from being improved, and dicts being ordered is pretty awesome. I'm pretty sure relying on unsorted dicts might involve pretty hacky code.

I recently stopped writing a z-order test application because I remembered that dicts are not sorted, so it made my goal a little pointless. Meanwhile C++'s std::map is sorted. I think there was already sorted dict in python, but I don't remember.

EDIT: I'm wrong, I'm mixing "ordered" and "sorted"

Re: Python dicts are now ordered

#57
post #20

Earlier quoted context omitted.

I'm not clear on how this break existing code. Code that assumed it was arbitrary, would expect to handle any arbitrary order, including a happens-to-be sorted order. Code that assumed it was random, like actually inserted by random(), was already broken, because that simply isn't the case. Code that assumed the order would stay constant was relying on implementation-specific behavior, and could potentially break on…

It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python

What you describe is forward compatibility, and Python (and most other programming language) doesn't have it.

Re: Python dicts are now ordered

#58
This is not new.. it's an implementation side affect as mentioned. Previous to this though the order was random according to a random string generated each time a python process launched; so you would get the same order in one process, and a different order when you restarted it.

Re: Python dicts are now ordered

#59
post #28
post #15

Am I the only one that thinks this is a stupid decision? This will silently break code that starts to rely on this behaviour that gets executed on Python3.5 and lower. I would consider changing how a builtin works to be a major breaking change. It would have been fine if this was a change between 2 and 3 but on a minor version? Thats insane.

> I would consider changing how a builtin works to be a major breaking change. This one is unusual because it won't break old code being brought forward, only the other way around, and theoretically there are lots of things going the other direction that would break (though most of them are explicit, not silent).

In other words, it breaks backwards compatibility, but not forward compatibility.

Re: Python dicts are now ordered

#60
Great decision IMO. I remember maintaining a bunch of Python code that we supported on both OSX and Windows. Out of all the platform-specific bugs we had (where it worked on one OS and not the other), one of the most common causes was code that relied on a certain key order. And we knew that relying on key order was bad, we're supposed to use things like OrderedDict, blah blah blah. It was still a really easy mistake to make, just like it's really easy to have memory safety bugs in C.

At some point, if a human error is common enough, it makes pragmatic sense to change the design so the error is impossible.

Post reply on HN