Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python dicts are now ordered

softwaremaniacs.org

Post reply on HN
Print view View original

121–130 of 457 posts

Re: Python dicts are now ordered

#121

Post by UncleEntity »

throwaway8291 wrote: post #35
kyrra wrote: post #19

Earlier quoted context omitted.

Go purposely "randomizes" order of a map when it's iterated over, which you can see running this demo: https://play.golang.org/p/DISpyv0Zuq_j HN discussed this a little 6 years ago: https://news.ycombinator.com/item?id=7655948 As crawshaw pointed in that discussion, it helps catch people inadvertently relying on map order in tests or other places in their code.

That surprised me, when I first saw it. If someone takes a minute to read the docs (e.g. Python), one would never build something knowing that order is not guaranteed (e.g. order in dictionaries). But seemingly people do.

Had some code break while porting from 2 to 3 because it assumed dict order and it was part of the official Python build system, the old spark parser for the AST module.

Re: Python dicts are now ordered

#122

Post by tomp »

ipsin wrote: post #38
kyrra wrote: post #19

Earlier quoted context omitted.

Go purposely "randomizes" order of a map when it's iterated over, which you can see running this demo: https://play.golang.org/p/DISpyv0Zuq_j HN discussed this a little 6 years ago: https://news.ycombinator.com/item?id=7655948 As crawshaw pointed in that discussion, it helps catch people inadvertently relying on map order in tests or other places in their code.

More important (in my opinion), adding a random seed to your hash prevents collision attacks, where an attacker tries to ruin your performance by sending many values (e.g. HTTP params) that would hash to the same bucket.

Many (most?) programming language runtimes now do this, especially the web-focused ones. But it's completely orthogonal to insertion-ordered iteration (which is implemented by a list).

Re: Python dicts are now ordered

#123

Post by diN0bot »

ebg13 wrote: post #113
diN0bot wrote: post #111

question: does the following expression still evaluate to True with ordered dicts? {'a':1, 'b':2} == {'b':2, 'a':1}

Yes. Dict comparison doesn't rely on iteration order.

thanks :-)

i mean, i would hope not if it's an implementation detail and not a change in the abstraction itself... feels a bit like it is breaking the abstraction, though.

Re: Python dicts are now ordered

#124

Post by masklinn »

dehrmann wrote: post #79

I've written a lot of Python, but more Java. This is where I have a gripe with "batteries included." In Java, I'd have to think slightly about this, then use a LinkedHashMap. It's been in Java since *2002. It also has a Set flavor. Python just doesn't have as rich of a collection of included data structures, and the APIs are more limited.

What java calls linkedhashmap, Python calls ordereddict.

It's not quite as old as java's linkedhashmap but is no spring chicken either (it's a bit above 10 years old).

Re: Python dicts are now ordered

#125

Post by OJFord »

jkbbwr wrote: 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.

It's not breaking, it was implementation defined, now it's guaranteed order.

If a new guarantee or behaviour were a breaking change, every non-patch release of a semversioned tool (which python isn't) would be major.

Re: Python dicts are now ordered

#126

Post by dehrmann »

masklinn wrote: post #124
dehrmann wrote: post #79

I've written a lot of Python, but more Java. This is where I have a gripe with "batteries included." In Java, I'd have to think slightly about this, then use a LinkedHashMap. It's been in Java since *2002. It also has a Set flavor. Python just doesn't have as rich of a collection of included data structures, and the APIs are more limited.

What java calls linkedhashmap, Python calls ordereddict. It's not quite as old as java's linkedhashmap but is no spring chicken either (it's a bit above 10 years old).

Where's orderedset, though?

Re: Python dicts are now ordered

#127

Post by masklinn »

Sean1708 wrote: post #48
taeric wrote: post #10

This is a solid argument for why you should have more datatypes available to you. If your program relies on an insertion order, say so. If anyone ever moves to another implementation, they will thank you for it.

It's extra annoying because collections.OrderedDict has been in the standard library for ages.

I fail to see what's annoying how. OrderedDict provide features for manipulating ordering, but they are expensive and slower. dict initially became ordered as a consequence of implementation details changes, and that was considered useful enough (or likely enough to trigger compatibility issues with third party implementation) that the core team decided to standardise it rather than break it (one of the advantages of the new implementation is iteration performances, shuffling iteration would probably have slowed it back down more than the old implementation)

Re: Python dicts are now ordered

#128

Post by drngdds »

paulhodge wrote: post #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…

I haven't done a ton of Python, but I can't really think of a situation where relying on a dict to be ordered is an easy mistake to make. Do you have an example?

Re: Python dicts are now ordered

#129

Post by upofadown »

zackmorris wrote: post #93

I'm glad to see other languages finally catching up to PHP. I'm joking (kind of) but after a lot of years of doing this, I've begun de-prioritizing pure abstractions and favoring the way that humans tend to do things on their own. Technically this is along the lines of the worse-is-better philosophy. The single biggest cost in software development is friction. Performance, size, etc are all less important, because th…

>Performance, size, etc are all less important, because they become less important with each passing year as computers grow more powerful.

That isn't as true as it once was. We are running up against fundamental limits and people are even starting to talk about the environmental impact of computing.

Post reply on HN