Live data from Hacker News

Python dicts are now ordered

softwaremaniacs.org

181–190 of 457 posts

Re: Python dicts are now ordered

#181

Earlier quoted context omitted.

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 actual…

>The result was usually stupid but it was there

This is what I meant by "sane" in my comment. It's _way_ more meaningful to the user if data's insertion-ordered.

Re: Python dicts are now ordered

#182
post #164

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.

JavaScript Maps are iterated over in insertion order.

Re: Python dicts are now ordered

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

By that logic, any change would be considered "breaking" because people will expect that the change also exists in older versions.

Re: Python dicts are now ordered

#184
post #82

Earlier quoted context omitted.

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.

If you’re the only one writing it and you’re the only one running it, it’s probably fine. But if I’m putting a file out there that will only work in 3.7, it’d be nice if any potential users of that file would get a good error message if they try to run it on 3.5, rather than wrong results.

I could potentially assert a version, but do I really want to do that each time I wrote something that might be used somewhere else?

And yes of course I could add a line of documentation, but there is a 100% chance I’d still get bug reports from people on 3.5.

Re: Python dicts are now ordered

#185

Earlier quoted context omitted.

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.

And this change would be fine even if Python did.

Re: Python dicts are now ordered

#186
post #75
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.

Python 3.4 is EOL anyway so there's no need to do this. Anybody running 3.4 is already unsupported.

Re: Python dicts are now ordered

#187

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…

Especially with the (lack of) change to sets I'm interested to benchmark some regular things before and after the change.

    set(dict.keys())
    set(dict.values())
    thing1 = dict(...)
    thing2 = copy.deepcopy(thing1)
I feel like there could be some other testcases. I'm wholly in support of the change (regardless of benchmarks) but depending on the results I could see some arguments against.

Re: Python dicts are now ordered

#188
post #148

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.

> The dict is dead, long live the dict.

That’s like saying binary search tree is dead because the implementation uses a red-black tree.

Re: Python dicts are now ordered

#189

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…

I don't have any criticism if the performance of this new dict stays the same as earlier and that's a huge if. Considering python3 is already a crawling language compared to peers like java and php, I think devs should focus more on that before handing out features.

Re: Python dicts are now ordered

#190

Where "now" dates back to 2018? https://docs.python.org/3/whatsnew/3.7.html

Came to say the same.. insertion order of dict has been here for years for 90+% of Python users (CPython implementation) and a part of the language spec also for almost as many years.

I guess it’s good to spread awareness to HN readers who apparently were unaware, but the headline is very misleading.

Post reply on HN