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

161–170 of 457 posts

Re: Python dicts are now ordered

#161

Post by paulddraper »

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…

Internally, Google modifies Java and Python (and Go was made this way and Chrome made JS this way) so that the dictionary traversal is deterministic.

Re: Python dicts are now ordered

#162

Post by eatonphil »

rmdashrfstar wrote: post #155
gnulinux wrote: post #142

Earlier quoted context omitted.

Why does it matter if it's explicit or not. If python doesn't support forward compatibility, you should know that if you write code for 3.7, it's not gonna work in 3.5. Doesn't seem like a big deal to me.

Major version changes are for API compatibility. If there is a change which makes all other 3.* incompatible, then it should be a major version increase.

You're describing something like semver, but Python doesn't do semver.

Re: Python dicts are now ordered

#163

Post by hayd »

setr wrote: post #20
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.

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…

Dicts are ordered in certain cases in python 2, and it was relied upon by some users (I saw it in the wild).

Baking this as a language guarantee is the only protection against Hyrum's Law.

Re: Python dicts are now ordered

#164

Post by alayne »

_aleph2c_ wrote: post #144

This is an amazing contribution to the language. A mixture of speed and convenience, probably made by volunteers. As for people criticizing a change to what use to be a non-deterministic ordering of a dict iteration; I don't know what to say to them, other than, are you serious? There are people out there who are working for us, they work for free and they did some heavy lifting to give us this. They might read what…

Other languages don't generally have special order guarantees about standard maps. This seems very idiosyncratic.

Re: Python dicts are now ordered

#165

Post by throwaway287391 »

klyrs wrote: post #44
setr wrote: 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…

> Code that ordered the dictionary keys before iterating are now slightly innefficient due to extra work of sorting a sorted list. Dicts are ordered , specifically insertion-ordered, not sorted . Sometimes they'll be sorted: D = {i:i for i in range(10)} ... specifically, when you insert them in sorted order. But then you can break the sortedness on your next insert: D[-1] = -1 What it allows is parallel iteration: zi…

The property you mention at the end has been true of dicts since long before 3.5, at least since 2.7 if not forever. See https://docs.python.org/2/library/stdtypes.html#dict.items :

> If items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond. This allows the creation of (value, key) pairs using zip(): pairs = zip(d.values(), d.keys()).

Re: Python dicts are now ordered

#166

Post by toyg »

ebg13 wrote: post #146

For some definition of "now". Python 3.7 was released in June 27, 2018. So "now" is "for the past year and a half". Python 3.6, which implemented the change originally, was released in December 23, 2016. By that measure "now" actually means "for the past 3 years".

The whole Python 3 affair made me realise that a lot of people upgrade their tools like once every 5-10 years. Which is shocking, in an industry as fast as this. I’m not saying you should churn your whole build setup every 6 months (I think release speed for Python is a bit excessive at the moment, for example), but complaining in 2020 for a feature that was released almost two years ago, was in development for a year or so before that, and was widely publicised... I mean, c’mon.

Re: Python dicts are now ordered

#167

Post by brettcannon »

bbrik wrote: post #158
_aleph2c_ wrote: post #144

This is an amazing contribution to the language. A mixture of speed and convenience, probably made by volunteers. As for people criticizing a change to what use to be a non-deterministic ordering of a dict iteration; I don't know what to say to them, other than, are you serious? There are people out there who are working for us, they work for free and they did some heavy lifting to give us this. They might read what…

As far as I know, it was implemented by Raymond Hettinger. This is a very interesting talk about the new tech: https://www.youtube.com/watch?v=p33CVV29OG8&t=1202s

Raymond came up with the idea, PyPy implemented it, and then INADA Naoki implemented it for CPython.

Re: Python dicts are now ordered

#169

Post by shrimpx »

wutbrodo wrote: post #159
_aleph2c_ wrote: post #144

This is an amazing contribution to the language. A mixture of speed and convenience, probably made by volunteers. As for people criticizing a change to what use to be a non-deterministic ordering of a dict iteration; I don't know what to say to them, other than, are you serious? There are people out there who are working for us, they work for free and they did some heavy lifting to give us this. They might read what…

> As for people criticizing a change to what use to be a non-deterministic ordering of a dict iteration; I don't know what to say to them, other than, are you serious? There are people out there who are working for us, they work for free and they did some heavy lifting to give us this. They might read what you wrote and think, "Why bother? Maybe I should spend my weekends playing with my kids instead." I don't agree…

As it’s widely known, more often than not “criticism” of open source software quickly devolves into hate and toxicity. Helpful criticism is great but be careful with defending the “criticism culture” around foss, it’s often angry unhappy people that want it all for free on a golden platter, and yesterday.

Re: Python dicts are now ordered

#170

Post by hprotagonist »

ryebit wrote: post #75
harikb wrote: post #61

Earlier quoted context omitted.

The trouble is I publish a (new) code that advertises itself as working on 3.x and then it turns out it is being used by a person who only had the version prior to this change. That said, Go made a similar change (from insertion-order to explicitly-randomized) and world didn’t end. So there’s that.

If your code relies on a minimum python version, you can add `python_requires=">=3.5"` to your setup.py [ https://packaging.python.org/guides/distributing-packages-us... ] to ensure it's not installed on older releases. That field itself is kinda new; but if needing to block users with older versions, that shouldn't be an issue.

personally, i just drop a f-string in setup.py and that'll filter out any python for which this issue pertains.
Post reply on HN