3 ms·

We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page

We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief. Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017.

Jenda_ 4y ago
> Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017. For example GnuRadio started supporting Python 3 with GnuRadio 3.8 released in 2019, and then you had to port all your programs using it to this version. So no, in 2017, the ecosystem was not ready.
mike_hock 4y ago
> finding that the "python" command still launches a Python 2.7 apt install python-is-python3
- mrweasel 4y ago
  I don't think my co-workers would like that :-)
  - tux3 4y ago
    dpkg-reconfigure co-workers?
    - bb88 4y ago
      apt purge co-workers
- worldsayshi 4y ago
  I've broken a bunch of stuff when I tried to replace python 2 with 3.
Nextgrid 4y ago
The biggest danger in Python 2's unicode handling is that incorrect things somewhat worked (until you got a non-ascii character at which point it exploded or produced incorrect behaviour). I'm sure you could do things well in Python 2 with proper combinations of encode/decode, but it wasn't obvious where you even needed those because with ascii text, things "just worked" transparently. With Python 3 it's very obvious where you need encoding/decoding because bytes != str.
- vetinari 4y ago
  You could do things correctly in Python 2, but as soon as you used any third-party library in your project, chances were it is going to explode underneath you anyway. In the early 2000s, I maintained an py2, wxPython app with the users having the system encoding win-1250; the effort to patch this was unbelievable. The migration to python3-style handling forced everyone to think about these issues, not just few people for which things were crashing. Even just popularizing the issue was great, until then, many maintainers of third-party libraries didn't even understand what is the problem that you want to "needlessly complicated" fix in their libs.
heinrichhartman 4y ago
> That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief. The problem is not the end-user invoking the command. The problem is scrips expecting `#!/usr/bin/env python` to invoke python-2.
- deleted 4y ago
  [deleted]

Jenda_ 4y ago

> Personally I feel like they should have yanked Python 2 in Jessie (Debian 8) in 2015, more realistically in Stretch in 2017. For example GnuRadio started supporting Python 3 with GnuRadio 3.8 released in 2019, and then you had to port all your programs using it to this version. So no, in 2017, the ecosystem was not ready.

mike_hock 4y ago

> finding that the "python" command still launches a Python 2.7 apt install python-is-python3

mrweasel 4y ago
I don't think my co-workers would like that :-)
- tux3 4y ago
  dpkg-reconfigure co-workers?
  - bb88 4y ago
    apt purge co-workers
worldsayshi 4y ago
I've broken a bunch of stuff when I tried to replace python 2 with 3.

Nextgrid 4y ago

The biggest danger in Python 2's unicode handling is that incorrect things somewhat worked (until you got a non-ascii character at which point it exploded or produced incorrect behaviour). I'm sure you could do things well in Python 2 with proper combinations of encode/decode, but it wasn't obvious where you even needed those because with ascii text, things "just worked" transparently. With Python 3 it's very obvious where you need encoding/decoding because bytes != str.

vetinari 4y ago
You could do things correctly in Python 2, but as soon as you used any third-party library in your project, chances were it is going to explode underneath you anyway. In the early 2000s, I maintained an py2, wxPython app with the users having the system encoding win-1250; the effort to patch this was unbelievable. The migration to python3-style handling forced everyone to think about these issues, not just few people for which things were crashing. Even just popularizing the issue was great, until then, many maintainers of third-party libraries didn't even understand what is the problem that you want to "needlessly complicated" fix in their libs.

heinrichhartman 4y ago

> That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief. The problem is not the end-user invoking the command. The problem is scrips expecting `#!/usr/bin/env python` to invoke python-2.

deleted 4y ago
[deleted]