Live data from Hacker News

Python dicts are now ordered

softwaremaniacs.org

361–370 of 457 posts

Re: Python dicts are now ordered

#361
post #288

This is a refreshing update for those of us that like having code which will always act in the same way across multiple invocations. Now, if only Lua could follow the same path with their “tables” (“tables” is what Lua programmers call their form of Python’s “dictionaries” and Perl’s “hashes”). I just spent eight hours earlier this week debugging Lua code which would run differently on different invocations of the sa…

You can write an iterator yourself, no need to leave ?pairs idiom: function sortpairs(t) local keys = { } for key in pairs(t) do table.insert(keys, key) end table.sort(keys, function (a, b) return tostring(a)

What Lua is lacking here (and why the above iterator function needs 17 lines) is the ability to have “for” go through a list (without converting the list in to values returned by an iterator function), which would let us quickly and easily sort lists that “for” can use. Something like:

  d = {"foo": 2, "bar": 1, "zoo": 4}
  for k in sorted(d.keys()):
    print k
(I’m not advocating Python here, since Perl has a similar way of using “for” to go through lists which can also be easily sorted)

However, with Lua, “for” only accepts a numeric range, or an iterator function, so customizing “for” requires understanding function closures: Understanding how a function, when called multiple times, stores variables altered in previous invocations of the function, and understanding how to give those variables initial values (usually in the “function factory” function which creates the function we use).

In other words, “for”, in most modern high-level languages, can be one of:

1. for variable in [something that specifies a numeric range]

2. for variable in [iterator function]

3. for variable in [list]

But Lua only has “something that specifies a numeric range” and “iterator function”; it can not natively go through a list.

Re: Python dicts are now ordered

#362

Earlier quoted context omitted.

OrderedDict is slow and expensive though: it maintains ordering through a doubly linked list. It has useful features for manipulating ordering but while I've regularly needed had use for maintaining insertion ordering I can't remember ever needing to move items around within a map.

If memory serves me correctly, ever since dicts became ordered the OrderedDict simply became a subclass of dict, so it will have exactly the same performance characteristics.

Yup.

    >>> isinstance(OrderedDict(), dict)
    True

Re: Python dicts are now ordered

#363

Earlier quoted context omitted.

OrderedDict is slow and expensive though: it maintains ordering through a doubly linked list. It has useful features for manipulating ordering but while I've regularly needed had use for maintaining insertion ordering I can't remember ever needing to move items around within a map.

If memory serves me correctly, ever since dicts became ordered the OrderedDict simply became a subclass of dict, so it will have exactly the same performance characteristics.

OrderedDict was always a subclass of dict maintaining additional information (which is not free, it has to store and manipulate two pointers per entry).

It remains so today, ordereddict is not an alias or trivial facade to the normal dict because it has to maintain its doubly linked list and implement a bunch of additional operations based on that e.g. pop first or move to end.

Re: Python dicts are now ordered

#364
post #184

Earlier quoted context omitted.

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

If you write code that doesn't work in 3.5, you should check the version at startup and exit

Yes, that would be a good idea. But if you ever run scripts you didn’t write, there’s the potential people didn’t do this, and you have the potential for hard to discover bugs. The language should be designed such that bugs are difficult to encounter, this is an instance where it wasn’t.

Re: Python dicts are now ordered

#365

Earlier quoted context omitted.

If memory serves me correctly, ever since dicts became ordered the OrderedDict simply became a subclass of dict, so it will have exactly the same performance characteristics.

Yup. >>> isinstance(OrderedDict(), dict) True

That was already the case in python 2.7 or 3.1.

Re: Python dicts are now ordered

#366
post #184

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.

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

Setuptools solves this, add a python version specifier to your setup.py or pyproject.toml file.

If you are just distributing raw python files then congratulations you’ve just realised why packaging is valuable.

Re: Python dicts are now ordered

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

For anyone who came to Unit Testing with the XP era and happened to use Java, Java 5 introduced changes to hash table ordering that somehow resulted in Junit 3.0 running some tests in a different order.

It's important to discover coupling between your tests, this just isn't the way most people want to do it.

Re: Python dicts are now ordered

#368
post #347

Earlier quoted context omitted.

I literally just learned "bog-standard" 10 minutes ago and now I see it here. And no, don't Baader-Meinhof me, I would have noticed this weird term in random text in the past.

Baader-Meinhof denial!

Baader-Meinhof Dunning-Kruger?

Re: Python dicts are now ordered

#370
post #251

I live in the Python bubble, so I haven't realized until this post that so few people knew about that. This post is massively popular despite talking about a feature we had since Python 3.6, in 2016, that was posted on HN at the time and that is featured in most popular tutorials. A good reminder that most of the world doesn't revolve about my favorite language. And that information is not that fast to spread.

> about a feature we had since Python 3.6, in 2016 No, you had that feature in one implementation. Now it's in the language specification. That's vastly different because only now you can rely on it without fearing it can go away with the next release.

> rely on it without fearing it can go away with the next release

This is Python we're talking about.

Post reply on HN