6 ms·

> some Linux distributions already switched to version 3 At the lightning pace of only 12 years since the release of python 3 (and 15 months since python 2's d

> some Linux distributions already switched to version 3 At the lightning pace of only 12 years since the release of python 3 (and 15 months since python 2's deprecation), some linux distribution have ALREADY switched to it.

skohan 5y ago
The developer story around python 2/3 is emblematic of why I don't consider it a suitable language for software development outside of very controlled cases like notebooks.
- leetrout 5y ago
  Eh. That’s all passed. Now we’re arguing about pip vs pipenv / pip file or poetry.
  - kissgyorgy 5y ago
    No we are not :) poetry won, it's just way better than pipenv. In fact, pipenv was just always shit.
    - leetrout 5y ago
      Have you seen PDM? https://pdm.fming.dev/ https://pdm.fming.dev/
- smcl 5y ago
  I dunno, they made some big breaking changes but continued supporting 2.x for over a decade after 3.x. There are definitely reasons I would not consider Python for some projects, but the 2/3 transition is not one of them. To be honest the event is so infamous (and IMO a little overblown) that they basically couldn't do this anymore, and I think it's been openly stated that they wouldn't.
  - skohan 5y ago
    What gets me about it is that the 2/3 transition was just a massive unsolved problem, and one which caused pain over a decade after 3.x was released. Other ecosystems managed to solve it - like Rust for example handles editions in a very sound way - but with Python you had so many problems cropping up over the years over python versions.
    - formerly_proven 5y ago
      Okay, I'm just going to call bullshit on this. There's this tiny, very-very vocal minority of people who continue to mystify the 2/3 changes and act as-if migrating code were some massively difficult herculean task that almost ended Python. Sometimes a little bit of "string/bytes split is ALL WRONG and utter non-sense!" mixed in. The truth is, that these were not actually big changes. The truth is that some orgs just wanna sit on their lazy asses doing jackshit to maintain their stuff and are surprised that, after 15 years, they have to do MAINTENANCE WORK??? ON THEIR CODE??? This is an outrage! The truth is that if porting was hard, or difficult, the code most likely had no meaningful tests, and so you couldn't do any changes anyway. The truth is, that changes like these expose bad engineering. And guess what, people don't like being exposed.
      - kortex 5y ago
        Well, I think some companies had a massive conversion burden, but these are typically massive companies, like Google. Most companies had nowhere near as much python2 code. I think you hit the nail on the head with "lack of meaningful tests". The entirety of "locked to 2" python code I've dealt with was a serpentine mess with little/no tests and so brittle even going from print to logger risked things breaking. "But it currently works!"
        rbanffy 5y ago
        > "But it currently works!" Miracles happen, but people shouldn't count on them.
      - 5y ago
- whoknowswhat11 5y ago
  The problem was in part because they actively broke the 2/3 compat story. Ie someone into Unicode on 2 with u'' got hosed on 3 despite 3 going on and on about importance of string handling. How hard would it have been to support u so someone could support both versions more easily? It was insanity.
  - kortex 5y ago
    > How hard would it have been to support u so someone could support both versions more easily? Exceptionally hard. Py2 str objects are tantamount to py3 bytes but with the py3 str apis. What this amounts to is every "str" in py2 is an untagged union of str/bytes. Python is exceptionally dynamic. This means if you allow different behavior in different modules, you risk silent, customer-data-corrupting bugs, among other headaches, as things continue to "work" but do the wrong thing. At least with a hard 2/3 switch, you are on your toes and know there is a (mostly) finite transition period. from __future__ import str basically guarantees you'll have "3-compatible code" causing headaches years into the future. That's not even to touch on the difficulty of switching the engineering difficulty of interop of encoding-oblivious strings with unicode ones.
    - pseudalopex 5y ago
      Python 2 let you put a u in front of a string literal to make it unicode. Python 3 made it a syntax error at first. Python 3.3 restored it so people could write code compatible with 2 and 3 without importing unicode_literals.
  - formerly_proven 5y ago
    > How hard would it have been to support u so someone could support both versions more easily? Python 3 has supported writing u"foo bar" for a very long time, I think starting with 3.2 or so. Similarly, Python 2 accepts b"foo bar".
    - pseudalopex 5y ago
      It was Python 3.3. 4 years into what started as a 7 year plan.

skohan 5y ago

The developer story around python 2/3 is emblematic of why I don't consider it a suitable language for software development outside of very controlled cases like notebooks.

leetrout 5y ago
Eh. That’s all passed. Now we’re arguing about pip vs pipenv / pip file or poetry.
- kissgyorgy 5y ago
  No we are not :) poetry won, it's just way better than pipenv. In fact, pipenv was just always shit.
  - leetrout 5y ago
    Have you seen PDM? https://pdm.fming.dev/ https://pdm.fming.dev/
smcl 5y ago
I dunno, they made some big breaking changes but continued supporting 2.x for over a decade after 3.x. There are definitely reasons I would not consider Python for some projects, but the 2/3 transition is not one of them. To be honest the event is so infamous (and IMO a little overblown) that they basically couldn't do this anymore, and I think it's been openly stated that they wouldn't.
- skohan 5y ago
  What gets me about it is that the 2/3 transition was just a massive unsolved problem, and one which caused pain over a decade after 3.x was released. Other ecosystems managed to solve it - like Rust for example handles editions in a very sound way - but with Python you had so many problems cropping up over the years over python versions.
  - formerly_proven 5y ago
    Okay, I'm just going to call bullshit on this. There's this tiny, very-very vocal minority of people who continue to mystify the 2/3 changes and act as-if migrating code were some massively difficult herculean task that almost ended Python. Sometimes a little bit of "string/bytes split is ALL WRONG and utter non-sense!" mixed in. The truth is, that these were not actually big changes. The truth is that some orgs just wanna sit on their lazy asses doing jackshit to maintain their stuff and are surprised that, after 15 years, they have to do MAINTENANCE WORK??? ON THEIR CODE??? This is an outrage! The truth is that if porting was hard, or difficult, the code most likely had no meaningful tests, and so you couldn't do any changes anyway. The truth is, that changes like these expose bad engineering. And guess what, people don't like being exposed.
    - kortex 5y ago
      Well, I think some companies had a massive conversion burden, but these are typically massive companies, like Google. Most companies had nowhere near as much python2 code. I think you hit the nail on the head with "lack of meaningful tests". The entirety of "locked to 2" python code I've dealt with was a serpentine mess with little/no tests and so brittle even going from print to logger risked things breaking. "But it currently works!"
      - rbanffy 5y ago
        > "But it currently works!" Miracles happen, but people shouldn't count on them.
    - 5y ago
whoknowswhat11 5y ago
The problem was in part because they actively broke the 2/3 compat story. Ie someone into Unicode on 2 with u'' got hosed on 3 despite 3 going on and on about importance of string handling. How hard would it have been to support u so someone could support both versions more easily? It was insanity.
- kortex 5y ago
  > How hard would it have been to support u so someone could support both versions more easily? Exceptionally hard. Py2 str objects are tantamount to py3 bytes but with the py3 str apis. What this amounts to is every "str" in py2 is an untagged union of str/bytes. Python is exceptionally dynamic. This means if you allow different behavior in different modules, you risk silent, customer-data-corrupting bugs, among other headaches, as things continue to "work" but do the wrong thing. At least with a hard 2/3 switch, you are on your toes and know there is a (mostly) finite transition period. from __future__ import str basically guarantees you'll have "3-compatible code" causing headaches years into the future. That's not even to touch on the difficulty of switching the engineering difficulty of interop of encoding-oblivious strings with unicode ones.
  - pseudalopex 5y ago
    Python 2 let you put a u in front of a string literal to make it unicode. Python 3 made it a syntax error at first. Python 3.3 restored it so people could write code compatible with 2 and 3 without importing unicode_literals.
- formerly_proven 5y ago
  > How hard would it have been to support u so someone could support both versions more easily? Python 3 has supported writing u"foo bar" for a very long time, I think starting with 3.2 or so. Similarly, Python 2 accepts b"foo bar".
  - pseudalopex 5y ago
    It was Python 3.3. 4 years into what started as a 7 year plan.