31–40 of 457 posts
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.
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.
But, from a pragmatic angle, it strikes me as a genius move. As the article said, this was a natural by-product of a performance enhancement that was made in 3.6. In principle, that was fine, because there was officially no predictable ordering, so a change to how it was being ordered in practice shouldn't materially affect anyone. And nobody really paid much notice to it then.
And that's where the danger lies - there's risk there, because, as you said, someone who's used to Python 3.6 might have problems switching to 3.5. And that's probably a greater risk if they left it out of the spec, because people would have continued to not pay it much notice. By making it official in 3.7, though, they've sent out a message that the Internet hate machine has ensured that everyone will hear. That probably, in practice, actually reduces the risk.
And, while many understandably see this as violating the spirit of semver, it unambiguously does not break the letter: Minor changes are only supposed to avoid breaking the software's compatibility with code written against an old version. There was never any rule saying that old versions have to be compatible with code written against the new version.
Javascript taught me to never assume any ordering in a dict/map/hashmap (whatever the term)
These collections are often default defined as unordered collections; it’s just that people discovered over time that some were iterable even if the language docs said otherwise.
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'.
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.
Go purposely "randomizes" order of a map when it's iterated over, which you can see running this demo: https://play.golang.org/p/DISpyv0Zuq_j HN discussed this a little 6 years ago: https://news.ycombinator.com/item?id=7655948 As crawshaw pointed in that discussion, it helps catch people inadvertently relying on map order in tests or other places in their code.
Earlier quoted context omitted.
I'm not clear on how this break existing code. Code that assumed it was arbitrary, would expect to handle any arbitrary order, including a happens-to-be sorted order. Code that assumed it was random, like actually inserted by random(), was already broken, because that simply isn't the case. Code that assumed the order would stay constant was relying on implementation-specific behavior, and could potentially break on…
It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python
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?
Earlier quoted context omitted.
These collections are often default defined as unordered collections; it’s just that people discovered over time that some were iterable even if the language docs said otherwise.
I don't think ordering and iteration are related, are they? Whether something is sortable has no impact on whether it is enumerable.
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.
Go purposely "randomizes" order of a map when it's iterated over, which you can see running this demo: https://play.golang.org/p/DISpyv0Zuq_j HN discussed this a little 6 years ago: https://news.ycombinator.com/item?id=7655948 As crawshaw pointed in that discussion, it helps catch people inadvertently relying on map order in tests or other places in their code.
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?
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.