6 ms·

The optimization is awesome but IMHO the key ordering "benefit" in the implementation but not the spec is a so-so move: It can cause some future bugs in the co

by gbin 10y ago

The optimization is awesome but IMHO the key ordering "benefit" in the implementation but not the spec is a so-so move: It can cause some future bugs in the code assuming it is there. Some languages like Go added some key ordering randomization to maps to be sure to avoid people counting on any specific key order.

kough 10y ago
As long as the language specification is updated to specify ordered keys in dicts then this is good. The big complaint about key ordering I remember hearing is that it was basically a side effect of the CPython implementation (back in the 2.X days), but not part of the spec. If the spec won't be updated to specify that dict keys must be ordered, then I agree with you. EDIT: ganduG clarified below that this is just an implementation change. No bueno.
- kabdib 10y ago
  Many, many people won't read the spec. And their code will break when the implementation changes.
  - takeda 10y ago
    And what's worse, this kind of issue is hard to detect. At least with unicode the code was crashing most of the time.
d_theorist 10y ago
This was my thought as well. I haven't really followed the discussion around the decision, so perhaps I am missing something, but my initial feeling is that either ordering should be required by the spec and implemented, or the ordering should be randomised. But, that is the outcome of about 1 minute's thought :)
noobiemcfoob 10y ago
If the ordering of the keys is not in the spec, a programmer should not assume the ordering of the keys. If none of the training material says or implies that the keys will always be ordered, why would a programmer? The new and improved algorithm happens to preserve ordering. Future algorithms might not. The dictionary data structure does not specify order preservation so that, in the future, a better algorithm that doesn't have this same side effect could be used.
- d_theorist 10y ago
  > If none of the training material says or implies that the keys will always be ordered, why would a programmer? Because people make mistakes.
  - danso 10y ago
    Perhaps "should" is the better word. That is, a programmer should not assume the keys will be ordered.
    - d_theorist 10y ago
      Programmers should not try to access memory beyond the end of an array. They should not attempt to add ints and strings. They should not give a function a float when it expects a struct. But they do. So we try to design languages in such a way as to minimise the likelihood of these mistakes going unnoticed.
      - noobiemcfoob 10y ago
        Designing a language to minimize the likelihood of these mistakes is a motivation for language design, but usually far from the primary. "Programmers should not try to access memory beyond the end of an array" ^ Right, and when they do, it's called a logical bug, something to be fixed. A programmer relying on the incidental but unspecified behavior of a function would be making a similar mistake.
kabdib 10y ago
It's not so-so, it's a terrible idea. At a minimum, the implementation should cough up keys in (say) reverse order, or some cheap to implement different order than insertion order. Two years down the line, the amount of code that depends on insertion order will make it impossible to do further optimization. [Many years ago I wrote a platform with an unintended ordering scheme in its dictionary. The documentation stated in bold that order was not deterministic and could change. Users started reporting "bugs" when I changed the order. That sucked.]
- notdonspaulding 10y ago
  Ordered kwargs is in a PEP[0] that is in "Final" status, meaning it's been accepted and implemented and is making its way into the language proper. [0]: https://www.python.org/dev/peps/pep-0468/ https://www.python.org/dev/peps/pep-0468/ EDIT: On rereading, I see that the parent and GP aren't specifically talking about the kwarg-ordering benefit, but the general dict-ordering benefit. I would be surprised if dict did not become a synonym for OrderedDict in the spec in the near future. The only potential disadvantage of dict==odict is performance, as anyone relying on the current arbitrarily-ordered dict behavior by definition isn't worried about the underlying implementation moving to a deterministic-by-insertion-order dictionary.
  - kabdib 10y ago
    Still a terrible idea. Speaking from hard experience.
    - lukeschlather 10y ago
      I've never run into a case where the difference in performance between Dict and OrderedDict was important. I have dealt with legacy code (especially code that needs to interact with JavaScript libraries) where strict-ordering was critical and it was great that at the time I was using Ruby 1.9 in which dicts are explicitly ordered. I agree that waffling about it is bad, but I think ordered is a better default than unordered. All this stuff about deliberately trying to shuffle order to catch bugs just says to me that most code is a lot simpler to get right if dicts are ordered-by-default.

by gbin 10y ago

kough 10y ago

As long as the language specification is updated to specify ordered keys in dicts then this is good. The big complaint about key ordering I remember hearing is that it was basically a side effect of the CPython implementation (back in the 2.X days), but not part of the spec. If the spec won't be updated to specify that dict keys must be ordered, then I agree with you. EDIT: ganduG clarified below that this is just an implementation change. No bueno.

kabdib 10y ago
Many, many people won't read the spec. And their code will break when the implementation changes.
- takeda 10y ago
  And what's worse, this kind of issue is hard to detect. At least with unicode the code was crashing most of the time.

d_theorist 10y ago

This was my thought as well. I haven't really followed the discussion around the decision, so perhaps I am missing something, but my initial feeling is that either ordering should be required by the spec and implemented, or the ordering should be randomised. But, that is the outcome of about 1 minute's thought :)

noobiemcfoob 10y ago

If the ordering of the keys is not in the spec, a programmer should not assume the ordering of the keys. If none of the training material says or implies that the keys will always be ordered, why would a programmer? The new and improved algorithm happens to preserve ordering. Future algorithms might not. The dictionary data structure does not specify order preservation so that, in the future, a better algorithm that doesn't have this same side effect could be used.

d_theorist 10y ago
> If none of the training material says or implies that the keys will always be ordered, why would a programmer? Because people make mistakes.
- danso 10y ago
  Perhaps "should" is the better word. That is, a programmer should not assume the keys will be ordered.
  - d_theorist 10y ago
    Programmers should not try to access memory beyond the end of an array. They should not attempt to add ints and strings. They should not give a function a float when it expects a struct. But they do. So we try to design languages in such a way as to minimise the likelihood of these mistakes going unnoticed.
    - noobiemcfoob 10y ago
      Designing a language to minimize the likelihood of these mistakes is a motivation for language design, but usually far from the primary. "Programmers should not try to access memory beyond the end of an array" ^ Right, and when they do, it's called a logical bug, something to be fixed. A programmer relying on the incidental but unspecified behavior of a function would be making a similar mistake.

kabdib 10y ago

It's not so-so, it's a terrible idea. At a minimum, the implementation should cough up keys in (say) reverse order, or some cheap to implement different order than insertion order. Two years down the line, the amount of code that depends on insertion order will make it impossible to do further optimization. [Many years ago I wrote a platform with an unintended ordering scheme in its dictionary. The documentation stated in bold that order was not deterministic and could change. Users started reporting "bugs" when I changed the order. That sucked.]

notdonspaulding 10y ago
Ordered kwargs is in a PEP[0] that is in "Final" status, meaning it's been accepted and implemented and is making its way into the language proper. [0]: https://www.python.org/dev/peps/pep-0468/ https://www.python.org/dev/peps/pep-0468/ EDIT: On rereading, I see that the parent and GP aren't specifically talking about the kwarg-ordering benefit, but the general dict-ordering benefit. I would be surprised if dict did not become a synonym for OrderedDict in the spec in the near future. The only potential disadvantage of dict==odict is performance, as anyone relying on the current arbitrarily-ordered dict behavior by definition isn't worried about the underlying implementation moving to a deterministic-by-insertion-order dictionary.
- kabdib 10y ago
  Still a terrible idea. Speaking from hard experience.
  - lukeschlather 10y ago
    I've never run into a case where the difference in performance between Dict and OrderedDict was important. I have dealt with legacy code (especially code that needs to interact with JavaScript libraries) where strict-ordering was critical and it was great that at the time I was using Ruby 1.9 in which dicts are explicitly ordered. I agree that waffling about it is bad, but I think ordered is a better default than unordered. All this stuff about deliberately trying to shuffle order to catch bugs just says to me that most code is a lot simpler to get right if dicts are ordered-by-default.