4 ms·
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 downgr
by setr 7y ago
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?
- 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]