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

71–80 of 457 posts

Re: Python dicts are now ordered

#71

Post by harikb »

Sean1708 wrote: post #40
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.

My main issue with it is that if someone figures out an even better way to do dictionaries but it doesn't preserve insertion order, then that technique can't be used. But I certainly wouldn't call it a stupid decision, the problem is that once a behaviour is observable then people absolutely will start relying on it.

I think this is a key point. Since they advertised this, it became a commitment for all future versions. Sure they can break again in 4.0

Re: Python dicts are now ordered

#72

Post by elcomet »

Waterluvian wrote: post #31
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.

You can't walk Python code backwards anyway without already considering the minor version differences. eg. f'strings'.

Not only f strings, but any change really.. New operators, new methods on standard library objects... Python never guaranteed compatibility of new code with old interpreters.

Re: Python dicts are now ordered

#73

Post by muldvarp »

setr wrote: post #36
biddlesby wrote: post #26

Earlier quoted context omitted.

It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python

You're right, I read the gp too quickly. But in the case of downgrading, I'm fairly sure there's a number of other breaking changes that can't trivially downgrade minor versions. Like f-strings were only introduced in python3.6 as I recall. Async keyword only exists as of 3.4 as well I think?

Both of these would be syntax errors if you tried to execute them in earlier python versions. This change might break software completely silently.

Re: Python dicts are now ordered

#74

Post by [deleted] »

setr wrote: post #36
biddlesby wrote: post #26

Earlier quoted context omitted.

It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python

You're right, I read the gp too quickly. But in the case of downgrading, I'm fairly sure there's a number of other breaking changes that can't trivially downgrade minor versions. Like f-strings were only introduced in python3.6 as I recall. Async keyword only exists as of 3.4 as well I think?

[deleted]

Re: Python dicts are now ordered

#75

Post by ryebit »

harikb wrote: post #61
hprotagonist wrote: post #47

Earlier quoted context omitted.

If you know you're supporting old code, use OrderedDict. you arguably ought to anyway, for explicitness.

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.

Re: Python dicts are now ordered

#76

Post by blattimwind »

pfdietz wrote: post #4
dmitriid wrote: post #3

Javascript taught me to never assume any ordering in a dict/map/hashmap (whatever the term)

Is the ordering there at least fixed, or can it vary from run to run even on the same data, or between implementations or versions of the same implementation? EDIT: to clarify, I was asking about JavaScript there.

If the ordering is determined by a hash function and it's always the same it is likely a defect in the implementation, because keys can be easily chosen to cause massive performance degredation; essentially a DoS attack. That's why many dynamic languages these days use things like siphash with a random key.

Re: Python dicts are now ordered

#77

Post by nobleach »

iiodiiod wrote: post #30
nobleach wrote: post #9

Earlier quoted context omitted.

It is deterministic, but it's an odd rule-set. For example: `var o = { 3: 'foo', 1: 'bar', b: 'baz', a: 'quux' }` Will yield: `{1: "bar", 3: "foo", b: "baz", a: "quux"}`. Numeric keys get sorted. String keys are insertion-order. If key order is a priority, a Map should be used instead. Often when JavaScript's objects are used and a particular sort order is required, an accompanying (sorted) array is used.

(deleted--missed context)

Go do `var o = { 3: 'abc' }` and then `o[1] = 'def';` Now tell me the output of `o`. (Doing this in your console should suffice). Is that insertion order?

Re: Python dicts are now ordered

#78

Post by mark-r »

ouid wrote: post #52
hprotagonist wrote: post #47

Earlier quoted context omitted.

If you know you're supporting old code, use OrderedDict. you arguably ought to anyway, for explicitness.

right, so making it implicit is bad design

It's part of the zen of Python: Explicit is better than implicit.

Re: Python dicts are now ordered

#79

Post by dehrmann »

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.

Re: Python dicts are now ordered

#80

Post by manaskarekar »

elcomet wrote: post #69
manaskarekar wrote: post #59

Earlier quoted context omitted.

In other words, it breaks backwards compatibility, but not forward compatibility.

That's not what people call backward compatibility. Backward compatibility is the ability to run old code with new interpreters. This is not broken here. What's broken is the ability to run new code on old interpreters. But this is already broken at every python update (new operators, methods, syntactic sugar..). We could call it reverse backward compatibility.

I suppose the meaning of the term depends on what we consider to be the subject of the compatibility.

- backwards compatible code: new code can run on an old interpreter

- backwards compatible interpreter: old code can run on a new interpreter

EDIT: After some thought, you're right. The second description is the reasonable interpretation.

"python 3.7 is backwards compatible with python 3.6"

Post reply on HN