Python dicts are now ordered • Hacker News Board

Re: Python dicts are now ordered

#141

Post by nkozyra » Fri, Feb 07, 2020, 5:07 PM UTC

OJFord wrote: post #125

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.

> It's not breaking

And that's sort of the problem. If it was broken, you'd know it and you'd fix/rearchitect it. Instead, it will appear to work.

Re: Python dicts are now ordered

#142

Post by gnulinux » Fri, Feb 07, 2020, 5:08 PM UTC

jakear wrote: post #82

jhrmnn wrote: post #57

Earlier quoted context omitted.

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

Usually languages don’t have it in a very explicit way though. If I try to use f-strings in python 3.5 I get a very explicit syntax error. If I rely on ordered insertions in Python3.5 I get a potentially difficult to diagnose bug.

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.

Re: Python dicts are now ordered

#143

Post by masklinn » Fri, Feb 07, 2020, 5:08 PM UTC

geophile wrote: post #2

"Ordered dict" is ambiguous, and from the title I thought that key order was meant. Reading the article, I see that it's actually insertion order. Which makes much more sense. Key order would have been a much more significant change.

> I thought that key order was meant.

Surely that would be a sorted dict not an ordered dict.

Re: Python dicts are now ordered

#144

Post by _aleph2c_ » Fri, Feb 07, 2020, 5:09 PM UTC

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 you wrote and think, "Why bother? Maybe I should spend my weekends playing with my kids instead."

Re: Python dicts are now ordered

#145

Post by masklinn » Fri, Feb 07, 2020, 5:10 PM UTC

_verandaguy wrote: post #11

geophile wrote: post #2

"Ordered dict" is ambiguous, and from the title I thought that key order was meant. Reading the article, I see that it's actually insertion order. Which makes much more sense. Key order would have been a much more significant change.

Not to mention there's often no meaningful way to order by key value since keys can be any hashable values -- so things like this break this idea: _dict = {} _dict.update({MyObject: 3}) _dict.update({'MyObject': 3}) There's no ordering over _most_ hashable values since they span multiple types, so insertion ordering is the only sane way to do it.

A sorted map would be tree-based and require its keys to be orderable but not hashable. For instance Rust's HashMap has its key bound on Hash + Eq, while BTreeMap's is bound on Ord.

They're different data structures, with different use cases and different requirements.

> There's no ordering over _most_ hashable values since they span multiple types, so insertion ordering is the only sane way to do it.

Python 2 actually had total ordering of all values. The result was usually stupid but it was there.

Re: Python dicts are now ordered

#146

Post by ebg13 » Fri, Feb 07, 2020, 5:10 PM UTC

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".

Re: Python dicts are now ordered

#147

Post by gnulinux » Fri, Feb 07, 2020, 5:11 PM UTC

manaskarekar wrote: post #59

_bxg1 wrote: post #28

Earlier quoted context omitted.

> 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.

No, this change is backward compatible but not forward compatible. Old code (written for old interpreter) works in new interpreter; but new code (written for new interpreter) is broken in old interpreter.

Re: Python dicts are now ordered

#148

Post by Igelau » Fri, Feb 07, 2020, 5:11 PM UTC

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.

I agree, and I think it's troublesome that dict now means something more specialized than it did before and the language doesn't communicate this. The dict is dead, long live the dict.

I suspect it's the result of my Java goggles, because the distaste comes from a sense that this is analagous to if the Map interface suddenly always meant LinkedHashMap.

Re: Python dicts are now ordered

#149

Post by c-smile » Fri, Feb 07, 2020, 5:12 PM UTC

Same thing as in JavaScript : https://www.stefanjudis.com/today-i-learned/property-order-i...

Re: Python dicts are now ordered

#150

Post by ebg13 » Fri, Feb 07, 2020, 5:13 PM UTC

diN0bot wrote: post #123

ebg13 wrote: post #113

Earlier quoted context omitted.

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.

The definition of a dict hasn't changed. It's still defined as a set of key:value pairs. It just happens to also have a particular guarantee now that iterating over the keys will return them in insertion order.