6 ms·

python2: just works. If you install python2 you get the same stable version everywhere. python3: Oh, sorry, you used a feature that was added in 3.x and this s

python2: just works. If you install python2 you get the same stable version everywhere. python3: Oh, sorry, you used a feature that was added in 3.x and this system has 3.(x-1) so now you get SyntaxErrors, or worse, random runtime exceptions. If you can target a container, buildpack or a specific platform python3 is fine, but it's been terrible for developers and users since day one. At least, it's been terrible for me, which is why I still have a pile of stuff to port to python3. It's fine for something like go or rust to add new features in a dot release, where you just need to upgrade your development hosts. Besides, if it compiles it will work, no surprises later. But python3 adds new features in 3.5, 3.6, 3.7 and then immediately breaks all new code on older systems. Used f-strings? Now your code is broken on 3.5. A new feature used the walrus operator? Now your code is broken on any system that doesn't have 3.8 yet. And 'dead' python2 keeps working.

cheez 7y ago
I was surprised at the number of libraries that exist to port 3.7/3.8 stuff back to 3.5
- stOneskull 7y ago
  Probably because of Debian 9. Now new Debian 10 means there'll be staying at 3.7 for a long time.
chungy 7y ago
> python2: just works. If you install python2 you get the same stable version everywhere. > python3: Oh, sorry, you used a feature that was added in 3.x and this system has 3.(x-1) so now you get SyntaxErrors, or worse, random runtime exceptions. Maybe you were used to Python 2.7 only as "Python 2", but when it was in active development, major 2.x releases had the exact same thing. I had some serious troubles when the latest version of RHEL was on 2.4 while the rest of the world had 2.6 with very large changes. There were all kinds gross hacks just to make things work on an older, common version.
- mehrdadn 7y ago
  Are you talking about making Python 2.6 code work on Python 2.4, or about making Python 2.4 code work on Python 2.6? The parent is talking about the latter for Python 3 (edit: looks like I misunderstood, never mind), but you seem to be talking about the former. They're not the same thing.
  - chungy 7y ago
    Python doesn't break backwards compatibility like that. Code written against 3.0 will still work perfectly fine on 3.8; likewise for 2.0 code running against 2.7. Parent seemed to be talking about the reverse: going backwards, and implying that 2 didn't have major new features, even though it very much did.
    - mehrdadn 7y ago
      No, it does break backward compatibility, especially when they introduce new keywords, but also with stuff like: https://news.ycombinator.com/item?id=22928672 https://news.ycombinator.com/item?id=22928672
    - pansa2 7y ago
      > Code written against 3.0 will still work perfectly fine on 3.8 Not 100%. For example, using `async` as a variable name works in 3.0 but not in 3.8, where it is a keyword.
      - chupasaurus 7y ago
        Are you talking about PEP-0492? It was added in 3.5.2 with deprecation of previous behavior in 3.7, release dates of those are separated by exactly 2 years, with deprecation warnings in 3.6.
        pansa2 7y ago
        Looks like PEP 492 introduced `async` as a contextual keyword in 3.5, and it became a proper keyword in 3.7.
frenchman99 7y ago
Also, if you write library code, you can, and should probably have CI running against Python 3.0, this way at least your code doesn't break when used against a newer version.
mixmastamyk 7y ago
I got on python-dev recently and tried to make the case that breaking changes should be delayed to a X.0 release. It didn’t get very far, they seemed to determined to keep the current low predictability system. The response was they don’t have enough manpower. The though ignoring deprecated stuff a few releases doesn’t sound particularly hard. I suspect Guido just likes it that way. Btw, almost no one supports forward compatibility.
- EdwardDiego 7y ago
  If you parse Python 3.8.2 as Python3 8.2.0 then the versioning follows semver nicely.
- pix64 7y ago
  Then you end up with Python 2 vs Python 3
  - mixmastamyk 6y ago
    They've had small breaking changes on many minor releases. The difference is the scope of the breakage. Python 3.0 broke every project. Python 4.0 certainly wouldn't, they are very timid now. In comparison, these breaks are tiny in scope.
EdwardDiego 7y ago
> But python3 adds new features in 3.5, 3.6, 3.7 and then immediately breaks all new code on older systems. It really helps if you think of the versioning as 5.0.x, 6.0.x of Python3, then semver can be applied and you set your shebangs accordingly.
- justinsaccount 7y ago
  What is the shebang that one should use to run code that targets python3.8 on a system that only has python3.7 installed? If you use python3 it might randomly fail, if you use python3.8 will fail with 'No such file or directory'
  - EdwardDiego 7y ago
    Yep, the latter, I'd much rather a deterministic failure. Or if you're using something like Poetry to package your code, you can specify supported versions and then users of your code will be informed if they lack that Python. But then if you're trying to write portable Python 3 code without any need for the end user to be pyenv-ing stuff, you probably don't want to be writing 3.8 - off the top of my head, Ansible, for example, targets Python 3.5 for this reason. I'm not defending this btw, modern Python development is painful, and I taught myself to code in Python, so it hurts to see my first love so. I guess it would be nice if Python came up with something like Java's source/target which errors if you're using incompatible features.
esjeon 7y ago
Yeah, I think webdevs and univ students are overly vocal on the internet. They can usually enjoy the new tech, because that's how the industry makes $$$. But there are other parts of the world that don't move that fast. All those "migrate to Python 3" should changed to "develop new projects in Python 3" instead.

cheez 7y ago

I was surprised at the number of libraries that exist to port 3.7/3.8 stuff back to 3.5

stOneskull 7y ago
Probably because of Debian 9. Now new Debian 10 means there'll be staying at 3.7 for a long time.

chungy 7y ago

> python2: just works. If you install python2 you get the same stable version everywhere. > python3: Oh, sorry, you used a feature that was added in 3.x and this system has 3.(x-1) so now you get SyntaxErrors, or worse, random runtime exceptions. Maybe you were used to Python 2.7 only as "Python 2", but when it was in active development, major 2.x releases had the exact same thing. I had some serious troubles when the latest version of RHEL was on 2.4 while the rest of the world had 2.6 with very large changes. There were all kinds gross hacks just to make things work on an older, common version.

mehrdadn 7y ago
Are you talking about making Python 2.6 code work on Python 2.4, or about making Python 2.4 code work on Python 2.6? The parent is talking about the latter for Python 3 (edit: looks like I misunderstood, never mind), but you seem to be talking about the former. They're not the same thing.
- chungy 7y ago
  Python doesn't break backwards compatibility like that. Code written against 3.0 will still work perfectly fine on 3.8; likewise for 2.0 code running against 2.7. Parent seemed to be talking about the reverse: going backwards, and implying that 2 didn't have major new features, even though it very much did.
  - mehrdadn 7y ago
    No, it does break backward compatibility, especially when they introduce new keywords, but also with stuff like: https://news.ycombinator.com/item?id=22928672 https://news.ycombinator.com/item?id=22928672
  - pansa2 7y ago
    > Code written against 3.0 will still work perfectly fine on 3.8 Not 100%. For example, using `async` as a variable name works in 3.0 but not in 3.8, where it is a keyword.
    - chupasaurus 7y ago
      Are you talking about PEP-0492? It was added in 3.5.2 with deprecation of previous behavior in 3.7, release dates of those are separated by exactly 2 years, with deprecation warnings in 3.6.
      - pansa2 7y ago
        Looks like PEP 492 introduced `async` as a contextual keyword in 3.5, and it became a proper keyword in 3.7.

frenchman99 7y ago

Also, if you write library code, you can, and should probably have CI running against Python 3.0, this way at least your code doesn't break when used against a newer version.

mixmastamyk 7y ago

I got on python-dev recently and tried to make the case that breaking changes should be delayed to a X.0 release. It didn’t get very far, they seemed to determined to keep the current low predictability system. The response was they don’t have enough manpower. The though ignoring deprecated stuff a few releases doesn’t sound particularly hard. I suspect Guido just likes it that way. Btw, almost no one supports forward compatibility.

EdwardDiego 7y ago
If you parse Python 3.8.2 as Python3 8.2.0 then the versioning follows semver nicely.
pix64 7y ago
Then you end up with Python 2 vs Python 3
- mixmastamyk 6y ago
  They've had small breaking changes on many minor releases. The difference is the scope of the breakage. Python 3.0 broke every project. Python 4.0 certainly wouldn't, they are very timid now. In comparison, these breaks are tiny in scope.

EdwardDiego 7y ago

> But python3 adds new features in 3.5, 3.6, 3.7 and then immediately breaks all new code on older systems. It really helps if you think of the versioning as 5.0.x, 6.0.x of Python3, then semver can be applied and you set your shebangs accordingly.

justinsaccount 7y ago
What is the shebang that one should use to run code that targets python3.8 on a system that only has python3.7 installed? If you use python3 it might randomly fail, if you use python3.8 will fail with 'No such file or directory'
- EdwardDiego 7y ago
  Yep, the latter, I'd much rather a deterministic failure. Or if you're using something like Poetry to package your code, you can specify supported versions and then users of your code will be informed if they lack that Python. But then if you're trying to write portable Python 3 code without any need for the end user to be pyenv-ing stuff, you probably don't want to be writing 3.8 - off the top of my head, Ansible, for example, targets Python 3.5 for this reason. I'm not defending this btw, modern Python development is painful, and I taught myself to code in Python, so it hurts to see my first love so. I guess it would be nice if Python came up with something like Java's source/target which errors if you're using incompatible features.

esjeon 7y ago

Yeah, I think webdevs and univ students are overly vocal on the internet. They can usually enjoy the new tech, because that's how the industry makes $$$. But there are other parts of the world that don't move that fast. All those "migrate to Python 3" should changed to "develop new projects in Python 3" instead.