3 ms·
I feel the same way as you do. For me, which version of an interpreter I'm using should be the kind of issue I only need to worry when solving extremely specifi
by probably_wrong 7y ago
I feel the same way as you do. For me, which version of an interpreter I'm using should be the kind of issue I only need to worry when solving extremely specific, deep-level problems. Python 3+ breaks this pact too often for my taste.
Considering this f-string example taken from another announcement:
f"Diameter {(diam := 2 * r)} gives circumference {math.pi * diam:.2f}"
This is valid Python 3.8, but it's not valid in Python 3.7 (no walrus operator). And removing the walrus operator still doesn't work in Python 3.5 (no f-strings). On top of that, other comments already mention how f-strings have lots of weird corner cases anyway.
The entire point of Python in my circle of friends was that it made programming easy. Instead, I feel more and more in need of those "It works in my machine!" stickers. And good luck solving these issues if you are not a full-time programmer...
- Liquid_Fire 7y agoI'm not sure why you frame this as an issue with Python 3. This has always been the case, even in the 2.x days every release added new features, and if you ran code using them in an older version it wouldn't work. The minor releases are always backward-compatible, so just run the latest version and everything will work.
- omginternets 7y agoThe issue is that the ecosystem as a whole tends to follow the tip of the version chain. This means that any human-oriented Python stuff (e.g. documentation/tutorials/code-review/etc...) requires you stay up to date with the language changes. Asyncio was the worst culprit, as it essentially introduces an inner-platform with its own dataflow semantics, but at least there the upsides were large and tangible.