9 ms·
It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python
by biddlesby 7y ago
It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python
- setr 7y agoYou'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?
- ses1984 7y agoIntroducing things is different than changing things.
- deleted 7y ago[deleted]
- setr 7y agoSure, but you can't safely take everything from a higher version to a lower version in any case; if insertion order became gauranteed due to a bugfix, and wasn't backported, you'd be in the same boat. The only way to consistently code cross-version is to start with the lowest you plan to support (assuming the higher versions are actually backwards-compatible). Does any language gaurantee that code is both backwards and forwards compatible?
- peteradio 7y agoIssue seems to be silent incorrect behavior, what happens if you attempt to run python code containing f-strings using an older python version. Does it raise an exception? That's good! What happens now if you write code for 3.7 which takes advantage of the new ordering and someone grabs it from your repo and runs it using 3.2, it would happily give incorrect results and noone is the wiser.
- rflrob 7y agoI think the argument is that if you run code with f-strings and walruses on Python 3.5, the code will break noisily. Whereas if your code implicitly relies on ordered dicts, it could break silently. Syntax errors rarely cause subtle, hard to track bugs.
- muldvarp 7y agoBoth of these would be syntax errors if you tried to execute them in earlier python versions. This change might break software completely silently.
- deleted 7y ago[deleted]
- dbcurtis 7y agoCPython is mot the only Python. Portability is an issue also.
- maxnoe 7y agoThis ja why it is now a language feature. Every python implementation that claims python 3.7 compatability must implement this. The other why around is also true, code that relies on it must specify that it requires python >= 3.7
- setr 7y agoPortability isn't affected; if they claim compatibility with python3.7, then they claim their dicts have insertion-ordered keys. If they claim compatibility with only up to python3.6, they can have whatever order they choose. The only issue with portability is that I think the main reason it was made a gaurantee is that cpython found the new, presumably optimized, implementation came with insertion order for free, so they went ahead and gauranteed it. But that might not be an optimal strategy in other areas, but they're forced to follow along anyways. But actually moving cpython code to say ironpython should not be impacted, unless ironpython lies about it's compatibility
- masklinn 7y agoThat also goes both way: Pypy defaulted to ordered dicts a few years before cpython did.
- maxnoe 7y agoThe insertion order dict implementation actually comes from pypy
- masklinn 7y agoThe insertion order dict implementation comes from Raymond Hettinger who is amongst other things a core CPython developer. pypy pulled the trigger on using it first (and probably has optimisations CPython doesn't). PHP also used it before CPython did, IIRC. And possibly Rust (as the third-party indexmap).
- hprotagonist 7y agoIf you know you're supporting old code, use OrderedDict. you arguably ought to anyway, for explicitness.
- ouid 7y agoright, so making it implicit is bad design
- mark-r 7y agoIt's part of the zen of Python: Explicit is better than implicit.
- skedaddle 7y agoPython is nothing like its guiding principles. That's why it's Zen -- the principles are a collection of contradictory statements, given what you will encounter in real world Python. You're meant to be confused and meditate on it.
- harikb 7y agoThe 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.
- ryebit 7y agoIf 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-using-setuptools/#python-requires 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.
- 7y ago
- jhrmnn 7y agoWhat you describe is forward compatibility, and Python (and most other programming language) doesn't have it.
- jakear 7y agoUsually languages don’t have it in a very explicit way though. If I try to use f-strings in python 3.5 I get a very explicit syntax error. If I rely on ordered insertions in Python3.5 I get a potentially difficult to diagnose bug.
- gnulinux 7y agoWhy does it matter if it's explicit or not. If python doesn't support forward compatibility, you should know that if you write code for 3.7, it's not gonna work in 3.5. Doesn't seem like a big deal to me.
- rmdashrfstar 7y agoMajor version changes are for API compatibility. If there is a change which makes all other 3.* incompatible, then it should be a major version increase.
- eatonphil 7y agoYou're describing something like semver, but Python doesn't do semver.
- dmurray 7y agoAnd this change would be fine even if Python did.
- gnulinux 7y agoWho told you that? I'm looking at PEP 606, it says nothing like what you claim. https://www.python.org/dev/peps/pep-0606/ https://www.python.org/dev/peps/pep-0606/
- andybak 7y agoWhat versions of Python didn't have this behaviour? It was there but just not guaranteed. I don't see how anything could break (unless there are alternative implementations with different behaviour I'm not aware of?)
- masklinn 7y ago> It was there but just not guaranteed. Dicts have been effectively ordered since 3.6. Iteration order was literally randomised (at process start) before 3.6. I'm also not sure whether the behaviour under deletion was changed between 3.6 and 3.7 so it's possible that there are subtle differences there.
- takeda 7y agoWell... full support for 3.6 ended in December of 2018 (now it only has security fixes), the older versions are already unsupported. Also, this change was implemented 3.6, but in 3.7 they officially documented it as a language feature (i.e. that all other Python implementations also need to preserve the order).
- ehsankia 7y agoFurthermore, there's a lot more stuff that are not backward compatible after 3.6 or 3.7, and if you're writing a library that targets other versions, I would hope that you have tests for all said versions.
- njharman 7y ago> Code written for Python 3.7 might break on older versions of Python That's a truism. For all versions of Python. If you use feature of python ver X, you should not be surprised that it doesn't run on versions less than X that lack that feature!!! If you write a Python library and use feature of Python ver X and don't mark library as only >= Python ver X, you are doing it wrong and a horrible person.
- nicklarsennz 7y agoDo you mean to say the future should be constrained by the past? I get the whole principal of least surprise, but not at the expense of progress.