3 ms·

I tend to agree that this is something that could be confusing to rely on, especially if running tests against multiple version of Python (such as a previous ve

I tend to agree that this is something that could be confusing to rely on, especially if running tests against multiple version of Python (such as a previous version where this isn't the behavior). Explicit is better than implicit. There should be one-- and preferably only one --obvious way to do it.

hayd 10y ago
In python 2 the ordering was deterministic. Cue lots of weird bugs when upgrading to python 3. Of course, it should never have been relied on... but it had been. I'd prefer either a completely random order or a completely deterministic one - but please no take backs (people will rely on it).
- Retra 10y ago
  I'm not sure anybody should be relying on code that relies upon the order of an unordered dict.
  - masklinn 10y ago
    These reliances usually aren't explicit, they just happen to work that way and it can be very hard to tease out the dependency unless you have a way to easily screw with iteration order. Pretty much any unspecified but (because of implementation) reliable ordering will eventually end up with code relying on it, usually implicitly, e.g. some Go code broke in 1.5 (and the release notes noted it explicitly) when scheduling order changed[0] despite it always having been undefined. In fact, specifically to catch this kind of hidden dependencies the Go developers added limited scheduling randomisation to the race detection mode. [0] from definition-ordering to last-definition-bias e.g. if you launched 3 goroutines 1, 2 and 3, in 1.4 the scheduler would just run them in that order, in 1.5 it would run 3 first followed by 1 and 2.
    - Retra 10y ago
      That's true, but to rely on these behaviors is to introduce bugs into your code, and we should be detecting and correcting them, not forgoing semantically clean optimizations because someone's buggy code will break.
camel_Snake 10y ago
And so we get a 3rd way to interpolate strings in 3.6.

hayd 10y ago

In python 2 the ordering was deterministic. Cue lots of weird bugs when upgrading to python 3. Of course, it should never have been relied on... but it had been. I'd prefer either a completely random order or a completely deterministic one - but please no take backs (people will rely on it).

Retra 10y ago
I'm not sure anybody should be relying on code that relies upon the order of an unordered dict.
- masklinn 10y ago
  These reliances usually aren't explicit, they just happen to work that way and it can be very hard to tease out the dependency unless you have a way to easily screw with iteration order. Pretty much any unspecified but (because of implementation) reliable ordering will eventually end up with code relying on it, usually implicitly, e.g. some Go code broke in 1.5 (and the release notes noted it explicitly) when scheduling order changed[0] despite it always having been undefined. In fact, specifically to catch this kind of hidden dependencies the Go developers added limited scheduling randomisation to the race detection mode. [0] from definition-ordering to last-definition-bias e.g. if you launched 3 goroutines 1, 2 and 3, in 1.4 the scheduler would just run them in that order, in 1.5 it would run 3 first followed by 1 and 2.
  - Retra 10y ago
    That's true, but to rely on these behaviors is to introduce bugs into your code, and we should be detecting and correcting them, not forgoing semantically clean optimizations because someone's buggy code will break.

camel_Snake 10y ago

And so we get a 3rd way to interpolate strings in 3.6.