zlacker

[return to "Perl's decline was cultural"]
1. deafpo+93[view] [source] 2025-12-06 18:12:16
>>todsac+(OP)
Perl6/Raku killed Perl.

Python 3 almost killed Python.

It's normal. Once a community loses faith, it's hard to stop them from leaving.

◧◩
2. MangoT+24[view] [source] 2025-12-06 18:19:24
>>deafpo+93
> Python 3 almost killed Python.

People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.

◧◩◪
3. symbog+B4[view] [source] 2025-12-06 18:22:24
>>MangoT+24
Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later
◧◩◪◨
4. jordan+k6[view] [source] 2025-12-06 18:35:25
>>symbog+B4
It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.

Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton.

At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.

◧◩◪◨⬒
5. JoshTr+u9[view] [source] 2025-12-06 18:59:08
>>jordan+k6
With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.

Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.

◧◩◪◨⬒⬓
6. kstrau+Vn[view] [source] 2025-12-06 21:07:26
>>JoshTr+u9
That split between bytes and unicode made better code. Bytes are what you get from the network. Is it a PNG? A paragraph of text? Who knows! But in Python 2, you treated them both as the same thing: a series of bytes.

Being more or less forced to decode that series into a string of text where appropriate made a huge number of bugs vanish. Oops, forget to run `value=incoming_data.decode()` before passing incoming data to a function that expects a string, not a series of bytes? Boom! Thing is, it was always broken, but now it's visibly broken. And there was no more having to remember if you'd already .decode()d a value or whether you still needed to, because the end result isn't the same datatype anymore. It was so annoying to have an internal function in a webserver, and the old sloppiness meant that sometimes you were calling it with decoded strings and sometimes the raw bytes coming in over the wire, so sometimes it processed non-ASCII characters incorrectly, and if you tried to fix it by making it decode passed-in values, it start started breaking previously-working callers. Ugh, what a mess!

I hated the schism for about the first month because it broke a lot of my old, crappy code. Well, it didn't actually. It just forced me to be aware of my old, crappy code, and do the hard, non-automatable work of actually fixing it. The end result was far better than what I'd started with.

◧◩◪◨⬒⬓⬔
7. JoshTr+Bw[view] [source] 2025-12-06 22:26:33
>>kstrau+Vn
That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).
[go to top]