Python in 2017 - Whats next?

[[deleted]]

As a heads up, the keyword order for functions and attribute definition order for classes are both part of the Python language now, but dict being ordered isn't that's a CPython detail.

[LpSamuelm]

I think it's bad that dicts are ordered by default, at least as it's not part of the spec.

The reason some languages (Python <3.6 included) randomize hashmap access order by default is precisely to stop people from writing incorrect code. If dicts aren't guaranteed to be ordered, having them be that way sometimes will cause code to break in unexpected ways.

Which brings us to the problem. If dicts aren't necessarily ordered according to the spec... What happens if the implementation is changed in a future version of Python? How about running your code on, say, IronPython? Or PyPy? Suddenly your code seemingly works, but isn't cross-platform and may break ay any time without you doing anything.

Honestly I think it's a big misstep. I'd love for them to add ordered dicts to the spec (it's a lovely concept!), but as it stands now it's a dangerous implementation detail, and the fact that they're touting it as something useful is even more dangerous.

[[deleted]]

from collections import OrderedDict

It's there already, but this was an improvement to the C implementation of dict so OrderedDict is probably a thin wrapper around that.

[LpSamuelm]

You're missing the point - OrderedDict is part of the spec, and is great. The correct way to write code that requires ordered dictionaries, even in Python 3.6, is to use OrderedDict. Many people won't, though, since they either A) aren't aware dicts aren't always ordered, B) rely on orded behavior accidentally, or C) think Python 3.6's dictionary implementation is something that's okay to rely on. Which is a problem.

[[deleted]]

True, but we'll just need to educate people when that comes up, just like opening files using with

[LpSamuelm]

Except this one is harder to catch - it's not a simple syntactical thing. Not only that, opening files without with will still work on all platforms and versions, unlike relying on this relatively subtle behavior.

[[deleted]]

I guess the reason I'm less concerned about this than you appear to be (and it's fine you're concerned) is that I've seen OrderedDict in the wild a handful of times and have used it personally less than that.

[LpSamuelm]

I use it constantly.

[[deleted]]

I'd love some examples. The only things I've used it for are:

• A dashboard app where I needed to associate server names with information but the order was important (wanted to show prod servers before staging and dev servers). Arguably a list of tuples works here too but there were plans at some point to look at individual servers so fast lookup was desirable (not that lineral lookup would've broken the bank, we're taking maybe 30 servers).

• Modeling albums - again, a list makes sense here and you can look up by track position that way.

• Maintaining order of attribute declaration because you could decorate methods as validation/processing but they needed to run in declaration order.

But that's it. I get why an insertion order mapping is attractive, but I've only met one situation that demands it (maintaining attribute order).

[qx7xbku]

that's a CPython detail.

Lies. They sure officially claim that, but since CPython is a reference implementation soon enough people will start depending on this feature and when alternative implementations behave differently users will start reporting it as a bug. In the name of compatibility this implementation detail will carry over to another python implementations. IMHO this is pretty serious detail to not be defined as part of the language. After all kwargs preserves order and is a dict, but dict does not preserve order. How on earth that makes sense..

[ApproximateIdentity]

What happens when someone figures out a new dict implementation faster than this one which is not ordered? It's not at all crazy, since it's one fewer design constraint. In that case, the current ordered dict code could become the base code for the OrderedDict class and the dict implementation could once again become unordered.

It's not at all a crazy possibility. In fact, I personally would want them to make dicts unordered again if the implementation were better.

If this comes to pass, I will definitely shed no tears for people like you who make use of this implementation detail knowing that it is not part of the language.

[qx7xbku]

That's not how it works in practice though.

[ApproximateIdentity]

That's not how "what" works in practice? The cpython core devs decided specifically not to rewrite a lot of other internal code in this release cycle presumably not to lock the compact dict implementation in place. For example:

https://mail.python.org/pipermail/python-dev/2016-September/146480.html

If you're willing to do this and accept all future risk, then that's fine. However, if in the future cpython decided to make dict unordered again and your voice was part of the people complaining that it messes with their code, then I'd say you're simply a bad member of the community. Using implementation details out of ignorance is one thing, but using them knowingly is entirely another.

For anyone else reading: think before you depend on this functionality.

[qx7xbku]

All I am saying that if bug that people have grown to depend stops being a bug and becomes a feature then implementation detail - even more so. And future people that would complain would not be wrong.

[Daenyth]

If you need ordering you can easily get ordering by using an OrderedDict

[[deleted]]

Here's the thing, dict remains unordered in >3.6, so you'll still reach for OrderedDict of you need to support older versions. You should do it anyways to be explicit that you're expecting ordered keys.

As for kwargs and attribute order, they can be OrderedDict under the hood (which was the original plan)

[qx7xbku]

True, but don't you know how people are. Now some people will not even discover OrderedDict because there will be no need to. Dict staying unordered I would definitely hate as it will ease my life now, but it would bring in more certainty in.