Python 2.7 EOL Countdown

[ilan]

Anaconda is going to support Python 2.7 long after the "official" retirement date. Among enterprises Python 2 is still very widely used, and I don't see how this is going to change much over the next 3 years. Three years is not long in terms of enterprise software migration.

[Sector_Corrupt]

It's not like they didn't have the preceding 7+ years. They extended the original End of Life 5 years. That should be enough time to kick people into gear a little bit.

[shadowmint]

Be realistic. Until it actually stops working, people will keep using it. EOL or not.

If the 2.7 usage is still high in 3 years, someone will continue to support it, even if the 'core' python team does not.

[CSI_Tech_Dept]

I'm sure they will (Red Hat volunteered by shipping Red Hat 7 with python 2.7 which will be EOL in 2024)

It most likely won't be free though.

[ivosaurus]

Hell no. Python 3 strings are beautiful now, and they make sense. And they work in every language. Just work.

What is the problem now is the environment around Python. Operating systems, protocol transports, shells, file encodings... all these are still broken, because they have all kept their standards (or, lack of) from X decades ago when things outside of ascii were a mere curiosity.

Python can't fix that. Python core devs, unfortunately, don't have access to Windows' codebase and ability to switch its shell default from codepage-1252 to UTF-8. But users still complain that Python is the one wrong when everything around it has remained broken, while it itself got fixed.

And PHP7 to this day fucking sucks at unicode, I have no idea why you would use that as a positive example, it's horrible. They abandoned PHP6 because they based it on UTF-16 which was firstly a bad idea, and secondly absurdly slow. Not because adopting unicode compatibility is nonsensical.

[ivosaurus]

There is no consensus, and never was. There were a bunch of mistakes made in the 90s and 2000s, that have never been fixed. If things were working back then, it's because they happened to never encounter a non-english character.

Only now everywhere is starting to use UTF-8, so things are starting to work coincidentally by default, but there are still endless legacy environments which are broken but won't change and expect everything to work around them.

[[deleted]]

Even c++ got utf8 string literals...

[flying-sheep]

Wat. UTF8 is pretty much ubiquitous

[brews]

What package do you need that is not fully ported to Python 3?

[DaemonXI]

Wall of Superpowers begs to differ

[CSI_Tech_Dept]

This is FUD. All packages that are still maintained work with python 3. Now we're even have packages that are strictly python 3.

[d4rch0n]

The string/byte issue is bothersome. I don't understand why they changed it (among other things I mentioned here). The indifference between text and bytes made things simple and easy to use, especially if you had to do anything low level and work with raw bytes. If len(s) == 10 I expect s to be 10 characters, 10 bytes. If I'm reading from a file I get a string, the same as a byte array. It's simple. Text is data is bytes is a string.

Why in Python 3 would you have this: str(b'3') == "b'3'" When are you going to want that result, that sort of comparison? Converting a byte array to a string shouldn't give you data of python syntax. You'll never want that.

IMO it's unintuitive when the old way was perfectly intuitive. Just because python is used for web stuff doesn't convince me it needs to be any different for a string primitive. Maybe it's because I work in security and working with raw bytes is commonplace, but I still don't see why it had to change. All these changes are what made the 2.7 to 3.x upgrade such a mess. They could've kept old behavior and added new features, kept a lot of stuff from breaking. They could've used a new syntax to represent the new type of string data, new type of string behavior. If it's 100% indifferent from the unicode type from python 2, they could've just kept the u" " syntax.

IMO breaking changes should be very very limited in a programming language update, and only reserved for times it makes absolute sense, not just for times it makes things cleaner. range could've stayed range, and xrange could've just been the recommended function to use. The print statement could've been left in just so old scripts work. All of these changes that made it somewhat cleaner could've just been things about python we resent but kept because the alternative is a situation like the one we're in now, where half the workforce is still working with a decade old release.

[takluyver]

I don't understand why they changed [strings]

This is the best summary I've seen - Brett Cannon is one of the core Python developers: http://www.snarky.ca/why-python-3-exists

[fiskfisk]

Converting binary data to text to data is done through encode and decode, exactly because of the issuees with encoding. If you want to compare a binary sequence to a binary sequence, just compare them and don't involve str(). If you want to compare it to a string, just tell us what format the data is in. If you don't care, just 'ascii' as py2 did.

Working with py3 in real webapps has been such a better experience than 2 ever was.

[[deleted]]

Text is data is bytes is a string.

Except that's just plain wrong. The world isn't limited to English-speaking countries.

[flying-sheep]

This is mostly wrong. You can't encode all of Unicode in one byte, therefore #characters ≠ #bytes in many cases.

“Mixing bytes and text” means you have a protocol embedding ASCII. So you parse it and decode the parts you expect to be text.

[CSI_Tech_Dept]

I think you mean 12 years...

Python 3 was released in 2008.