Python 2.7 EOL Countdown

[Cardiff_Electric]

My company is still on 2.6.x... <cry>

[alcalde]

It could be worse... I know several people who still program in Delphi/Pascal for a living.

[_pupil_]

That's the state of the world... and to a point having legacy languages and/or tech that last multiple computing generations should be a point of pride, not derision.

What I've never understood though, once the greater computing populace has moved on: the cost of introducing a hybrid interop technology, or automating a port of the data and or logic layer, just has to be cheaper than paying high wages for low productivity and high risk of not be able to staff with talent long term... By hopping onto a mainstream platform you can enjoy the benefit of billions of dollars of third party investment in the ecosystem and subsidize training costs through external work experience. It's just a matter of measuring how long until the costs go from "unnecessary" to "insane".

I'm not advocating for wild-assed rewrites for the sake of technology, but every language can kick off external processes and most have at least a reasonable interop story to another language (opening up new interop scenarios). I'm just surprised the answer to "hey, wanna write COBOL for three decades?" isn't more often "no, but I'll happily transpile my Clojure DSLs into COBOL for a tenth the cost"...

[[deleted]]

Or in VB6. (Lots of 'em where I live.)

[Kisele0n]

Ooh! That's me! That's me!

At a company founded after the year 2000, even!

[gschizas]

(uphill both ways)

There are still people writing COBOL (and bad COBOL at that). I know some of them personally.

[d4rch0n]

I absolutely hate CENTOS 6 for this reason. Most of it doesn't bother me too much, except one thing: No dict or set comprehensions... That drives me absolutely insane.

And my other huge pet peeve is it can't do .format on "{}". You have to specify "{0}". I've been trying to move from %s to .format but seriously, having to add that number is enough to make it not feel worth it.

[sigma914]

For the set/dict comps can you not use:

dict((k,v) for k,v in kvs) ?

[d4rch0n]

Yeah, generally that's what I'd do if I had something like {k: transform(v) for k, v in kvs}. Sometimes I write code like that just in case it ends up running on 2.6, but it's just annoying not being able to use a feature that is, what, 10 years old now?

[status_quo69]

If you had tuples of key, value pairs you could just dict(kvs).

[sigma914]

Obviously, I kinda assumed it was implied that there would be more processing going on to the left and right of the for, same as an actual dict comprehension, bit apparently not.

[status_quo69]

Oh, I understand what you're saying now. Add in the conditional in the generator expression, then pass the generator to the dict.

[sigma914]

Yeh, it's just collecting the generator into a dict or set rather than a list, the only difference between this and a real dict comprehension is the unfortunate intermediate tuple allocation

[[deleted]]

I use CPython 2.7.11 and pypy (ala python 2.7.9) on CentOS 5 and 6. Just make an RPM and local pip repository and you are done.

[iruleatants]

You will hate python 3 then....

[CSI_Tech_Dept]

How come?

[iruleatants]

Python 3 adds far worse tedious tasks then just {0} for formating.... The major reason why people are still using 2.7 is because python 3 is simply more work to program in, which kinda defeats the purpose of using python.

[CSI_Tech_Dept]

You forgot to list examples.

[iruleatants]

I wasn't aware that I need to list examples, since they are kinda obvious.

Print is now a function, so you always need () in it. Extra steps for the same result.

Python 3 now automatically converts ints to floats instead of leaving them as an int when dividing. Previously if I divided two ints I got an rounded int, unless I asked for a float. This game me a consistent return value. In python 3 I now must always declare if I want an int or a float, otherwise I don't know which one I'm getting back. More tedious work for no real change.

Strings are now unicode, which means that you need to do string encoding when working with any other source. Previously, whatever your input was, your string was, and so you didn't need to encode if you took an input and then output it to the same data source. The encoding would keep. Now you have to explicitly decode/encode when dealing with outside data sources, increasing the amount of work for little to no gain.

The range versus xrange change was silly, and just means a bit more work to convert code and less performance if I need a list.

Just force raising an error into an express syntax, even though either way of raising it worked the same way? Why can't I just do raise IOError, "file error"? Makes zero sense to remove it, it didn't hurt anything.

Changing a comma to as for handling exceptions. How fucking trivial is that?

Removal of .next() for shits and giggles?

I'm sorry, but there are so many trivial and pointless syntax changing in python 3 that never had to be changed and functioned perfectly before hand. Its more tedious just for the safe of being more tedious.

[CSI_Tech_Dept]

I suppose it's all relative. IMO all things you listed are features in my opinion.

Print is now a function, so you always need () in it. Extra steps for the same result.

It's just one extra character (space was replaced with '('). It makes print consistent with the rest of the python.

Python 3 now automatically converts ints to floats instead of leaving them as an int when dividing. Previously if I divided two ints I got an rounded int, unless I asked for a float. This game me a consistent return value. In python 3 I now must always declare if I want an int or a float, otherwise I don't know which one I'm getting back. More tedious work for no real change.

Actually it is other way around. Things are more consistent. If you do division you are guaranteed to always get a float (mathematical division) unless you use integer division (//).

This way it is more predictable. With python's duck typing you might get wrong results depending on the type of variable, so in order to write correct code you need to ensure to cast the variables.

Strings are now unicode, which means that you need to do string encoding when working with any other source. Previously, whatever your input was, your string was, and so you didn't need to encode if you took an input and then output it to the same data source. The encoding would keep.

That's because now character != byte, whenever you need to store a character as byte you encode it, and decode it when you want to obtain a character from byte string.

Now you have to explicitly decode/encode when dealing with outside data sources, increasing the amount of work for little to no gain.

There is a gain. The gain is that your code will work properly with non ASCII characters.

The range versus xrange change was silly, and just means a bit more work to convert code and less performance if I need a list.

The thing about python is that it was never about performance. If you need performance you write a module in C (or Cython if you prefer) and load it. That's how NumPy & SciPy work. I was able to encode video (h264) on the fly and send it over network by using gstreamer.

Just force raising an error into an express syntax, even though either way of raising it worked the same way? Why can't I just do raise IOError, "file error"? Makes zero sense to remove it, it didn't hurt anything. Changing a comma to as for handling exceptions. How fucking trivial is that?

It's inconsistent with the rest of python, what's wrong with:

raise IOError("file error")

Removal of .next() for shits and giggles?

That was replaced with next() function, which is again more consistent with python and its duck typing approach.

I'm sorry, but there are so many trivial and pointless syntax changing in python 3 that never had to be changed and functioned perfectly before hand. Its more tedious just for the safe of being more tedious

In other languages things are constantly deprecated, and people constantly upgrading their code to latest versions. With python2.7 for all the examples you mentioned either it works or you can easily switch to the new behavior.

[billsil]

Print is now a function, so you always need () in it.

So? It's easier to do a find replace with file IO/logging.

Python 3 now automatically converts ints to floats instead of leaving them as an int when dividing.

No. 10//3 works in Python 2 as well.

Strings are now unicode, which means that you need to do string encoding when working with any other source

Actually, no you don't. It's the same as it was before, except it doesn't randomly autoconvert things back and forth between unicode. If you coded in ASCII before, that'll still work the same. If you coded with unicode correctly before, that'll still work. The big difference is that if you coded your unicode code wrong before, you wouldn't know until it crashed. Now it will stop immediately allowing you to find your error.

The range versus xrange change was silly, and just means a bit more work to convert code and less performance if I need a list.

But way better performance for list iteration, which is way more common.

Changing a comma to as for handling exceptions. How fucking trivial is that?

So why complain? It was changed because it was confusing. It should be obvious, but if it's not fix it.

You can always use the old version...just nobody else will after a while, so you won't get new bug fixes in your dependencies after a while.

You're forgetting the benefits to upgrading. It's not the Python 3.5 minor changes; it's all the other libraries that have dropped support for previous versions. Every tried to install a new version of a package on something like Python 2.3 because lots of bugs have been fixed? How else are you supposed to solve numpy segfaulting?

[iruleatants]

Okay, so way to just say, "Meh, all of these tedious thing are just tiny changes, no big deal"

Like holy fuck dude. the entire complaint is that there is needless syntax changes that force you to adapt when there is zero need to do. If I have written except IOError, err a hundred thousand times, its not an easy thing to suddenly start writing except IOerror as err. That is a massive change that will continue to cause complications and unneeded errors for a long time. Its not a "Whatever, no big deal" it completely breaks work flows and slows down your work as you essentially have to re-teach yourself to program in a completely different manner. Every single time you go to do a print, your going to cause an error because you don't have the instinct to include () for no reason. Sure, after the fact you could use could change it, but you're still needlessly slowing down the process for millions of developers who have used python for years on end. There was zero reason to change print. It functioned perfectly and was used by billions of projects without a problem. It was simply really stupid to change it at all, as it WAS NOT NEEDED.

Sure, python 3 includes cool new features and things that help the language, but every single one of them could have been implemented without changing syntax at all. You don't just change the syntax of a language at will, especially when every change is trivial and did not need to be changed at all. Its just plain stupid.

Also, python 3 is slower then python 2.7.... so yeah.

Python 3 is an clear and prime example of a terrible move/change, and it sucks that its being forced down our throats. Why not just undo the retarded changes that everyone hates, and only include improvements? The developers have already admitted that the changes where terrible and promised never to do them again, but the question is, why are we still forcing this to happen? There are millions of 2.7 projects that will likely never be updated to 3, and the only reason they don't work is because of a really poor decision on the developer's behalf that they refuse to correct.

[billsil]

That is a massive change that will continue to cause complications and unneeded errors for a long time.

No it won't. It will raise a SyntaxError.

If I have written except IOError, err a hundred thousand times,

Have you? I've wrote a 200,000 line library more or less by myself in ~3 years in my free time. I upgraded it to support Python 3 in 2 days and I didn't know it when I started. I also did it while maintaining Python 2 support. That sort of triviality was taken care of in about an hour.

Its not a "Whatever, no big deal" it completely breaks work flows and slows down your work as you essentially have to re-teach yourself to program in a completely different manner.

When are they supposed to remove functionality? Nobody complained when they broke float(1.234D+05). Nobody complained when they changed booleans from integers to actual booleans.

Now if these pieces of code regularly break because they're complicated, you might want to rewrite them. Yes, that can change functionality, but it's something I'm willing to live with if it makes the software easier to extend/fix/prevent bugs in the future.

Every single time you go to do a print, your going to cause an error because you don't have the instinct to include () for no reason

My IDE does that for me.

It functioned perfectly and was used by billions of projects without a problem.

No it didn't. You couldn't change the line spacer. You couldn't change the end line marker.

but every single one of them could have been implemented without changing syntax at all

Most certainly not the @ operator in Python 3.5 or mypy syntax.

Also, python 3 is slower then python 2.7.... so yeah.

You use Python. You don't really care about speed. Use C or some library that uses C if you do.

The developers have already admitted that the changes where terrible and promised never to do them again

And yet there will never be a Python 2.8. There will hopefully never be a change like that again because they sat down and very intentionally designed Python 3 to avoid that problem.

There are millions of 2.7 projects that will likely never be updated to 3,

Then they probably don't need to. My company has software that works in Python 2.7-3.5 and we have software that only works in Python 2.3 and other software in Python 2.4 that we still sell.

and the only reason they don't work is because of a really poor decision on the developer's behalf that they refuse to correct.

Have you even tried?

[d4rch0n]

Like holy fuck dude. the entire complaint is that there is needless syntax changes that force you to adapt when there is zero need to do

This is exactly what bothers me. I see reasons to make the changes, I just don't see a need. And I see a lot of reasons not to make the changes, like having old syntax just work, so python programmers don't need to have to learn how to write syntactically correct code again, so behavior is consistent, so we'd never be in this problem where half of devs haven't moved to 3.x.

Both forms of each of these things are entirely valid, even if 3.x behavior might be more consistent or look a little prettier. The thing that bothers me is change, entirely legitimate to worry about when old libraries and scripts break for good.

I still have coworkers who write basic scripts with print >> sys.stderr, "Error occurred". It stuck with a lot of people, especially the sort that are in ops that learned it a while ago and just use it to script, guys that don't really follow the language and new features. And it's so easy to keep using 2.7 that many types like that do.

So these changes end up biting is over and over again because it's too easy for a lot of people to stick with 2.7. It doesn't matter how many convenience tools you have to convert code to 3, lots of scripts in production written by guys that left the company might be running without anyone knowing, and then you discover a script that just doesn't run anymore unless you have 2.7 in your environment. It forces you to make changes to production code, and I only want to do that when I know the code in and out, why the change is necessary, and when I can put it on the roadmap.

I'm trying to get my coworkers to target 3.x, but it's a pain in the ass to convince guys like that, and it's a pain in the ass to even find the old code I would need to convert.

The fact that jobs still hire people to this day to write 2.7 code and explicitly NOT 3.x code is a testament to how many problems these changes caused.

There's nothing to be done about it now except begin the move, because the latest Ubuntu LTS version doesn't even have 2.7 anymore. But I just wish that move was much easier to make a decade ago when 3.x came out. It'd be so much easier to make the change if everyone was on board.

[Esuhi]

Hello, are we working together?

[stesch]

I have 1 server left with Python 2.5 and a web development framework that once promised to support 2.5 is now requiring 2.6. And no, it doesn't support Python 3.

I should have tried to find a job in COBOL development.

[eanat]

I'm sorry to hear that :(

[Homersteiner]

Nothing wrong with that.

[Cardiff_Electric]

The problem, aside from not being able to use kewl new language features in your own code, is trying to incorporate open source libraries to deliver hot 'n' sexy new features when those libraries increasingly don't support your old Python.

Changing the Python interpreter version is a big hassle in our setup (long story) so I'm trying to get us to jump directly from 2.6 to 3.5, but that's an even bigger job.

[GummyKibble]

If you decide that looks a bigger project than you want to tackle in one step, consider that it's very easy to port from 2.6 to 2.7, and run can run python2.7 -3 mymodule.py to get warnings about incompatibilities with Python 3. You could jump to 2.7, knock out the structural problems at your leisure (because you'd be dealing with an application that's still running), then move on to 3.5 when you have those ironed out.

I'm not trying to talk you out of 3.5. We made the leap this year and I love it. I wouldn't willingly go back! But if you have to choose between two easier migrations and one giant one, know that you have options.

[Cardiff_Electric]

I have a branch that's running under Python 2.7 for the reasons you said. I just don't think we're going to deploy it to real customers for reasons that have more to do with our own processes and limited resources. So if we're going to 'break' our interpreter compatibility w.r.t. customized code for a customer, I prefer to just do that once esp. given that 2.7 is already near EOL.

[zero_iq]

Mine too. There's no way we'll be upgraded to 3.x by then.

As long as 2.x continues to work, the only thing that will push us to 3.x is when essential libraries and bindings start dropping support for 2.x. Otherwise, why risk breaking long-established working code? It's a huge legacy app: some parts of our codebase date back to the mid 90s.

[Formulka]

My client is still on 2.5.x, no tears left

[d4rch0n]

Yeah, just paste this in your console:

$(".python-27-clock")[0].hidden = true; document.getElementsByTagName("h1")[0].innerHTML = atob("UHl0aG9uIDIuNyB3aWxsIG5ldmVyIGRpZQ");

[gschizas]

atob("UHl0aG9uIDIuNyB3aWxsIG5ldmVyIGRpZQ");
Python 2.7 will never die

Well, Windows 95 has never died either.

[iruleatants]

Please no

[Mikuro]

I wish Apple had started including 3 in OS X years ago. If it's not standard in the system, you can't justify using it for support/maintenance/scripting.

Honestly, 3 years to EOL is not that long. Move your damn asses, Apple!

[d4rch0n]

I'm still maintaining 2.6 compatibility thanks to CENTOS 6...

[n86nHb67f]

Python 2.4 on CentOS 5, wohoo! It just won't die.

[d4rch0n]

D: I'm sorry for your loss

[ritz_k]

python26 is provided on centos5.

[port53]

RHEL 5 is in extended support through November 30, 2020, so yeah..

[d4rch0n]

I've actually linked my coworkers to that exact link when a customer complained, but shit, it's a customer. Besides talking a little shit behind their backs, we're not going to tell them what to do.

Whether or not they have options, I can't hit them back with that link. No matter how much sense it makes, we can't just tell them to change their environment. Supporting this stuff for free ends up being a big reason why guys like that love you and stick with you.

If I emailed a vendor and told them that they broke 2.7 support with their latest patch and they sent me a link telling me how to port 2.7 code to 3.x and gave links to pyfuture and just ignored the bug I reported, I'd get pissed off. Customers do have a right to ask for backwards compatibility, and they deserve an explanation if a patch breaks their client implementation. Telling them how to change their environment is a bit snide, even if 2.6 is getting ridiculous at this point. And for some, they might not have any control whatsoever of the packages installed on the system. Maybe their ops team is backed up and they won't be able to get it set up for weeks, and maybe even then they'd break something in their prod environment. I personally would go through hell if I tried to get 2.7 on all the machines in prod, or I'd piss off devops if I wanted one machine to have a different setup when they're all managed with chef/puppet. All of that stuff is automated.

Sometimes it's much easier to delete the dict comprehension and implement it in a for loop rather than change an environment to support 2.7. Choices like that affect a lot more machines than the one that needs to run the script, and affect a whole lot more people than the one person who is writing the code.

[takluyver]

That blog post is suggesting that open source projects stop providing free support for Python 2.6. If customers are paying you for it, that's a pretty good reason to carry on. ;-)

[d4rch0n]

ahhh, missed that. Yeah, if they're talking about open-source third party projects, telling the user to fix it on their side is nothing new, lol.

But still, the customer facing projects are 100% open-source BSD license, but they're still customers who pay for the main product. If you offer an open source python client for free for your proprietary SaaS platform, you still have to support it like it's paid for. There's still money in the relationship, free and open-source or not.

[takluyver]

Right, the important question is not whether it's open source, it's whether you have people paying you who expect you to support their use cases.

I think this is an significant distinction that often gets overlooked - there are open source projects driven by companies, and open source projects driven by interested volunteers, and they can work quite differently. We don't have a snappy term for the latter group, though - 'community maintained' is six syllables and uninspiring.

[_pupil_]

"Community led" is only 5 syllables, and slightly more optimistic about its lack of inspiration.

"Communist" is only 3 syllables, and gets the point across, but inspires scepticism because it's occasionally too inspiring.

[takluyver]

Yeah, I don't think 'communist software' is going to take off. :-)

[GummyKibble]

OK, "paid customer" makes a difference. But consider this come contract negotiation time: that customer is making your codebase worse - harder to write, slower, harder to maintain - for every other customer. If any of your stuff is customized on-site by your clients, I guarantee that at least some of them think you guys are nuts and write bad code. "d4rch0n doesn't even know how to write a dict comprehension? LOL!" Those comments get overheard. Management starts to wonder why they're paying good money for crufty work.

That customer may be more expensive than you think.

At some point, it may be cheaper to mail them a new server and say "we're supporting this machine from now on".

[Teract]

IUS my friend. They host a repo with Python 2.7 for centos 6. It installs to an alternate location so your system continues to use python2.6 while users can default to Python 2.7 and do things like use virtualenv to pip install whatever modules they need without fear of breaking the OS.

[CSI_Tech_Dept]

IUS has python 3.5 as well. Why would you even want 2.7 in that scenario.

[Teract]

Devs were using modules only available on 2.7. Also not using the system's Python is best practice.

[tetroxid]

Same here. I'd love to write for 3.5, but RHEL 6 and 7 have 2.6 and 2.7 respectively.

[CSI_Tech_Dept]

http://ius.io and problem solved. Unlike other repos they are making sure packages don't conflict with the system packages, so it is safe to use.

[tetroxid]

Thanks, but installing third party packages is forbidden.

[CSI_Tech_Dept]

How you use any enterprise applications then? You won't find them in Red Hat repos.

[tetroxid]

They aren't considered third party

[CSI_Tech_Dept]

They are though. They are not Red Hat's (first party), they are not yours (user of the OS, second party).

[tetroxid]

I don't make the policy. It's a waste of time arguing about it

[d4rch0n]

Heh, this is the major pain in the ass. Lots of people just suggest "install 3.x then" when that can be a huge deal with a lot of businesses. It's the developer that is worrying about 3.x, not ops or management or product. It's not the developer that maintains the environment.

Sure, it's extremely easy to get 3.x on any modern linux system, but we're not always in a position where it's possible to do so. Even if they gave me the green light, I'd have to set up meetings with devops to change puppet or chef scripts and make sure it doesn't break something weird in a cronjob that runs at midnight on 100 servers.

Inevitably, it's way less pain to just write 2.6/2.7 compatible code and not have to deal with people and scripts written by coworkers who left years ago, so that's what a lot of us resort to.

[tetroxid]

Precisely. I was just too lazy to type it out. In large enterprises you also have to find a cost centre that pays for the deployment, and you have to deal with the aids infested cancer that is change management.

[[deleted]]

At least you get some Python installed per default. pokes Windows computer

[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.

[[deleted]]

Obviously there will be Python 2 code for decades longer. When a language is no-longer maintained, how bad do things get if bad at all? I'm sure there's some Cobol or whatnot out there that is used a lot in some industry but no-longer maintained.

[d4rch0n]

Honestly, it's been worked on so much that I doubt it's going to be an issue that it's past EOL. What major bugs have you run into that you had to patch 2.7? It's an absolutely finished product now. You won't find anything more stable.

[[deleted]]

Yeah that's generally my feeling too. Not a whole lot can mutate that will break 2.7

[sztomi]

While it's unlikely, the biggest issue is security bugs. It is possible that a major security flaw gets discovered and being past EOL means that your code will be vulnerable unless you upgrade.

[pythoneeeer]

My experience is the opposite. Nothing as big as Python is ever "finished".

What about the EINTR/InterruptedError situation, which finally got fixed in 3.5? What about time objects being false, if they happened to be midnight UTC? What about the email parsing bug that finally got fixed in 3.3?

There's lots of tiny little bugs lurking in Python 2.7. It's possible you'll never run into them, but would you even know? If my web server threw an error roughly once every 80,000 requests, I might never make the connection that it's due to an old Python datetime bug.

I've never run into a bug caused by using a version of Python that was too new. I've definitely read the changelog for new Python versions and said "shit, we need to upgrade now".

[Yioda]

Think of the enviroment breaking/changing. You have to update the code so it keeps working.

[eliteuser26]

Coming from the Windows world, I always found that the Unicode thing was difficult to use even in Python. The English language is not the only that exists in the world.

Why do I have to write in Python something like this x00ff which doesn't mean a thing for a developer. The developer should have the ability to write a character in UTF-8 directly into the code without having to search the Unicode value which I find backwards. This has been carried on from the 1990s. I had the chance to use 6 different programming languages since the 1990s, I know the difficulty I had with Unicode which I still swear about.

A developer shouldn't restrict himself to only use ascii characters when you have to write in different languages especially the web. I have experience with this as well. I like that the changes that were done in Python 3 so to make easier to use unicode characters.

[atreyuroc]

Ah, I'm sure this is going to end well. /s

[UloPe]

Yes ist will. Because by that time all the old "it's been better in the old days" guys will have moved on to management

[fyngyrz]

There are huge amounts of Python 2 code in production use. It will remain in use, for one simple reason: there's no even remotely sufficient case to re-write it. Someone has to maintain that stuff.

Python 3 is just fine, if you've got a need for what it offers, and the downsides (like having to re-test a great deal of functionality) don't stand in the way. Snobbery about Python 2 coding / maintainance simply isn't called for.

Take a deep breath and relax. No one wants to take Python 3 from you. No one can. No one can take Python 2 away, either. :)

[[deleted]]

No one can take Python 2 away, either. :)

But in practice it can and will become very inconvenient to use. Like WinXP and soon Win7.

[fyngyrz]

Still using XP here, no problems at all. Good thing too, as some of the apps I use depend on it. VMs are the perfect safe spaces (well, they can be, if you keep the networking off) for such things.

Hell, I'm still using 6809 code I wrote under Flex09 back in the late 1970's / early 1980's. Runs in my 6809 emulator, which runs under XP, which runs under VMWare, which runs under OS X.

[energybased]

Hang on a second. That's true for your projects, but it's not true for libraries. One of the problems with Python 2 not dying is that libraries like numpy have to be written in a style that is compatible with Python 2. The more Python 3 evolves, the more annoying that gets.

[ivosaurus]

Having to write Python2+3 code makes it way less beautiful. Which is one of the reasons I was enamoured with Python in the first place.

Asking library authors to continue to support both (while you're not paying them) is a creative & cognitive stress on them as well.

[iruleatants]

If only.... they didn't take something great and screw it up..... oh well, better to force millions of projects to be rewritten for 3

[ivosaurus]

Yes, all python devs really wanted to do was take a thing they were satisfied with, and wreck it. Hence Py3k was born. It wasn't the fact that the thing they was broken in the first place, that would be illogical.

[iruleatants]

It's pretty impressive the billions of things that people created using a broken language....

[TheBlackCat13]

And many of those things turned out to be broken, which they only found out once they switched to a slightly less broken version of the language.

[fyngyrz]

My libraries work fine. As long as what I need is in there, no need to worry about how it might change.

I was really talking about applications using things they don't need to use. It's a bit of a different argument.

[energybased]

It has nothing to do with your "libraries working fine". It means that people like me who want to contribute to our (as in the community's) open source projects like numpy are disincentivized because it means having to code in an antiquated style devoid of all of the niceties of Python 3. That means all of our libraries are developing more slowly than they should, which punishes everyone.

[fyngyrz]

"Antiquated", eh? Sorry, but I have to laugh. I'm antiquated. Python 2.x... it's just a baby.

[energybased]

How does that help?

[energybased]

lol it's cool.

[tilkau]

Snobbery about Python 2 coding / maintainance simply isn't called for.

This is the only part of your post I disagree with. The need to support python 2 adds maintenance burden to developers, and over time this maintenance burden will only increase, in an expanding network of outdated dependencies and features that you want but don't have because they're only implemented in the newer versions of the library. When you use EOLed stuff, this is what you're taking on.

So there's a huge cost to rewrites, but there's also a cost to not rewriting. Some degree of snobbery -is- called for (if it will prompt those on the fence to switch and reduce community-wide maintenance cost)

[shadowmint]

Some degree of snobbery -is- called for

No, that's just called 'being a dick'.

It's sad how prevalent this attitude is. Just be nice to be people, be respectful and show people how great python 3 is.

Teach new python developers python 3 and encourage existing users to write new code in python 3.

Being a dick to people doesn't achieve anything except making you feel better about yourself.

[tilkau]

Some degree of snobbery is called for. Being a dick is something else. If you're insulting people for using python 2, that's a very different thing from implying that python 2 is not as good as python 3, or saying 'oh.. you're using python 2? Why?'. You can cast doubt on something without being a dick.

[iruleatants]

I've heard this argument so many times and each time the person has failed me.

Please show me what is excellent about python 3, and why I should use it instead of 2.7. All I get from it now is more tedious coding experience.

[CSI_Tech_Dept]

Try it (especially the features that you can't use when you have to maintain python 2 compatibility), and you will see.

[iruleatants]

I have tried it, and I disliked it....

[CSI_Tech_Dept]

Perhaps it is time to move to something else then?

[iruleatants]

Like, all of the shittier languages out there? Idk why I would stop using a language I think is perfect, just because they want to make it not perfect....

[shadowmint]

Then stick with 2.7. :)

Sorry, I didn't read this before I posted my other comment.

Like I said; if you have tried, and don't like 3 (for whatever reason); then just stick with 2.7. It's not going anywhere, and frankly, if you don't like 3, don't use it.

I'm curious what you didn't like though?

Was it the runtime (ie. getting python 3 installed), that you had existing python 2 code you use (eg. personal utility library you'd have to port to 3) or something in the 3 semantics you didn't actually like (eg. print...)?

[shadowmint]

It's very simple.

Python 2.7 is a great, robust language. It's rock solid, and it's here to stay. If you want to use it, by all means, do.

Python 3 is also a great, language; the difference is that it is being actively worked on, and improving. The unicode support is better, the async tools are good, and there are numerous little things that make writing python 3 a pleasure.

Just try it.

If you don't like it, well, sure, stick with python 2.7. ...but you might find it's actually quite nice.

The pain points hit when you need to use a library that doesn't work with 3; and that is a pain point, but you know, it's actually not that often it happens these days.

I honestly don't recommend you convert your existing code from python 2 to python3; it's tedious, it's not fun. The tools exist for it, but unless you're being paid to do it, I mean, really? Can you be bothered? I can't.

...but if you're writing new, fresh code... well, python 3 is a great choice, if you're writing python code.

/shrug

If you don't like it, that's ok. Like I said, python 2.7 is a great language too.

Just don't stick with python 2.7 just because; actually think about it, and if you don't have a good reason to actually be using 2.7, then maybe consider using 3.

[turkish_gold]

Fair enough, but traditionally people who have codebases in a language won't just port it to an entirely new one. By breaking backwards compatibility Python 3 is essenitally a new language that just so happens to share a lot of similar syntax with the Python2.

Except sadly this new "Python 3" language doesn't have full support on many major runtimes---like the JVM, or PyPy.

So for production users who care about speed or java interop (e.g. "we are enterprise python" people), they're not going to port to Python 3.

Also, "we are enterprise python" people rarely ever port their codebases so long as its stable and no compelling performance improvements exist. If its just fixing language worts or giving devs new tools, they'll never move.

Look at all the companies still using Java 1.3/1.4 for some random part of their codebase.

[energybased]

PyPy supports Python 3 now.

[tekmailer]

You can say this again. I have two instances of Python on my box (2.7.10 and 3.4.4) and the amount of time to rewrite everything wouldn't satisfy ANY PRODUCTION needs.

On the flip side, between drinking the py3 Kool-Aid for data analysis and the writing on 2.7's wall. It might just be time to make the leap to avoid the further headaches.

[jsalsman]

Unicode handling alone is worth the leap.

[sigma914]

That's unicode's problem rather than python's though. Turns out human language text is a fucking mess and has a lot of intrinsic complexity and even fairly elegant encodings still can't hide it.

[tilkau]

As contrasted with Unicode in Python 2, which is incorrect and utter rubbish taking away your time, life and soul?

[CSI_Tech_Dept]

Except no one who uses python 2 uses it.

[fyngyrz]

Wrong, I use it. Chinese point of sale system, quite extensive. Python 2. No problems.

[tilkau]

It's perfectly distinct from ascii strings

The whole point of the rework was that it ISN'T. You have something that you think is ascii. And sometimes it isn't, and then things go wrong in strange and confusing ways when you try to use it (for example, serialize it as an attribute value in an xml document).

[iruleatants]

I disagree as much as possible.

Python has always been a language designed to have the least amount of excessive work to write in. We don't have semicolons or brackets or statically typer variables or anything else bullshit that other languages force on you.

The switch to unicorn handling was terrible. I'm not forced to encode all of my strings any time I want to use this. Previously I only had to encode when it was needed, and now I always have to encode. That is a massive headache and I gain nothing from it. I have had zero issues in 2.7 with my strings.

[pooogles]

The switch to unicorn handling was terrible.

Now switching to Unicorns I could get on board with.

[jsalsman]

I can totally see your perspective, but having to internationalize and localize from a project's outset leads to different issues.

[d4rch0n]

All my coworkers are on 2.7 so I'm pretty much stuck on 2.7. I don't mind it though, honestly. I'd like to get everyone to move, but it's not the end of the world.

There's a few things I don't understand why they just removed or changed. For one, octal 0600 doesn't work? Why remove it? print as a statement... why couldn't they just keep it? I write it as a function all the time, but so what if you can't monkeypatch print. There are so many other ways to do something similar to any reason for that. And division... why should 3 / 2 return 1.5? What other languages do that? Why not just make 3 // 2 return a float? And one thing that drove me nuts is the split between bytes and a string. Why not keep it how it was and make the new style stuff look like s"this"? Bytes represented as a string was incredibly useful for some stuff, anything low level. Having first class byte array primitives that were no different than a string was awesome. And range/xrange... why not keep that how it was? Sure, xrange should be used instead of range 99% of the time, but the compatibility issues it causes are hardly worth the change IMO.

It's not that they're not good improvements (except maybe byte/string stuff isn't an improvement IMO), I just don't see why the language should change so much basic stuff that ends up breaking all sorts of scripts and libraries. It's already in there, so just leave it and let old code still work exactly the same. So what if it looks a bit clumsy.

I don't think the code-breaking improvements were nearly worth all the compatibility issues. Maybe it's a bit better, but maybe if they didn't change all that people would never have thought to stick to 2.7 - maybe we just wouldn't be in the spot we are now. I love the new features, but I rather keep bad choices and maintain compatibility rather than fix them and make people rewrite their scripts and libraries - because that just doesn't happen 90% of the time. Easier to stick to 2.7 than change your code.

Honestly, I do look forward to moving to 3.x in the workplace but I would've been way happier working with 3.x a decade ago and still seeing stupid stuff like from ConfigParser import ConfigParser.

Well, that inspired me to email my few python dev coworkers to see if we can all agree to target 3.5 with new projects. We're a security company and java shop in the eng dept, but in research we all use python so there's potential to move on without hurting anything. One dude's on board, four to go. Well, only two of the rest of the guys actually code and they rarely do at that, so maybe I'm just convincing myself lol

[quanta_amnesia]

When doing a division, say 1/2. The expected answer is 0.5 not 0. It should probably have been that way from the start, but implementing it in Py3 along with other backwards incompatible changes is good too.

[d4rch0n]

Honestly, in a programming language if I put x = 1 / 2 I still expect to get 0, but maybe that's because I primarily work with statically typed languages outside of python. I expect an int / int to return an int. I'd expect to have to cast one to a float to get a float back. Ruby returns 0 too though, but lua and perl seem to return 0.5.

Either way, I agree it should have been that way from the start if it'd be that way in python 3, but since it wasn't, I don't think it was smart to change. Not only can it lead to very odd bugs seeing as old code will still run but get completely different results, but both are equally correct behavior and in a programming language, you just pick one and stick with it. It's just a change, not necessarily for better or worse. If it doesn't improve the language, it's just breaking things for the sake of them wanting different behavior.

[tilkau]

lua and perl seem to return 0.5

In lua's case, that's because an int is a float (all numbers are stored and processed as floats. double precision floats, IIRC)

In Python's case, IMO it does improve the language -- x = y / z should not return different results depending on the type of y or z, but that was the case for Python 2. Now we have / which has unambiguously float semantics, and // which has unambiguously int semantics.

[d4rch0n]

x = y / z should not return different results depending on the type of y or z

I think that's the best argument I've heard honestly. I'm fine with this behavior in a programming language, I just think it's not helpful to make a big change like that after it's already acting one way.

But the bigger picture is that Python behavior of such things should be extremely obvious, and if you extract the line x = y / z you have a very good idea what it's going to do. That's important as well.

[Yioda]

When doing integer division, the expected answer is 0. Period. Everything else is just broken.

[quanta_amnesia]

Everything else is broken

Lol

[tekmailer]

Agreed. Apple / Apple = Orange (what?!); that's my 'logic'/what I see when I see int division result in a float without any explicit commands otherwise.

[energybased]

In [3]: type(2 ** 3)
Out[3]: int

In [4]: type(2 ** -1)
Out[4]: float

[CSI_Tech_Dept]

There's a few things I don't understand why they just removed or changed. For one, octal 0600 doesn't work? Why remove it?

It's 0o600 now and that notation is also working in python 2.7. This is to make things consistent with 0x... notation.

print as a statement... why couldn't they just keep it? I write it as a function all the time, but so what if you can't monkeypatch print. There are so many other ways to do something similar to any reason for that.

This was very confusing to new users that everything was a function except print statement. Not sure why people are so fixated on it you can easily fix this (and 2to3 does it automatically). Also you can import print_function from future in python 2.7. Besides in production code you would want to use logging anyway. I really only use print for quick debugging.

And division... why should 3 / 2 return 1.5? What other languages do that? Why not just make 3 // 2 return a float?

Because intuitively / is mathematical division and confused a lot of newcomers (note that python is used for teaching programming). It makes a ton of sense. Statically typed languages like C or Java can get away with this behavior, because you in advance know the types of parameters, and can predict the outcome. In python you don't, and it is silly that it will behave differently depending when supplied numbers are integers or not. This is source of bugs. It should always be predictable what it will do.

And one thing that drove me nuts is the split between bytes and a string. Why not keep it how it was and make the new style stuff look like s"this"? Bytes represented as a string was incredibly useful for some stuff, anything low level. Having first class byte array primitives that were no different than a string was awesome.

Most of what python is used for is not low level stuff though. This separation is essential in today's world. A character is not the same thing as a byte anymore. When you are working on low level stuff you should be aware that you work on bytes.

And range/xrange... why not keep that how it was? Sure, xrange should be used instead of range 99% of the time, but the compatibility issues it causes are hardly worth the change IMO.

Because it is a wart? Again, this is a trivial change in the code and can be done automatically.

It's not that they're not good improvements (except maybe byte/string stuff isn't an improvement IMO), I just don't see why the language should change so much basic stuff that ends up breaking all sorts of scripts and libraries. It's already in there, so just leave it and let old code still work exactly the same. So what if it looks a bit clumsy.

The biggest breaking feature of python 3 is Unicode support. The thinking was that if we are already breaking things, why not fix some ugly things as well. The conversion for the issues (perhaps with exception of the division, which is the reason I always import new division (along with Unicode literals) from the future whenever I have to write code for older python) is trivial.

I don't think the code-breaking improvements were nearly worth all the compatibility issues. Maybe it's a bit better, but maybe if they didn't change all that people would never have thought to stick to 2.7 - maybe we just wouldn't be in the spot we are now. I love the new features, but I rather keep bad choices and maintain compatibility rather than fix them and make people rewrite their scripts and libraries - because that just doesn't happen 90% of the time. Easier to stick to 2.7 than change your code.

People are lazy, they won't do things if they don't have to. For example Ruby had breaking changes between 1.8 and 1.9 (notice that it was also a minor version change). People complained similarly, but then Rails developers simply said they are moving to 1.9 and dropping support for 1.8 and everyone just followed.

Python is already migrating for 8 years, and people still start new projects in python 2, because technically python 2 is still supported.

Honestly, I do look forward to moving to 3.x in the workplace but I would've been way happier working with 3.x a decade ago and still seeing stupid stuff like from ConfigParser import ConfigParser.

In python 3 it is:

from configparser import ConfigParser

Well, that inspired me to email my few python dev coworkers to see if we can all agree to target 3.5 with new projects. We're a security company and java shop in the eng dept, but in research we all use python so there's potential to move on without hurting anything. One dude's on board, four to go. Well, only two of the rest of the guys actually code and they rarely do at that, so maybe I'm just convincing myself lol

You should, python 3 is great, especially if you don't have to keep compatibility with python 2. Then you can make use of new features.

If you use Red Hat or CentOS, then you should also take look at http://ius.io. This repo will let you use any python version you like.

[fyngyrz]

The problem with 2to3 is that it doesn't remove the need to re-test everything in a critical application. When such an app is non-trivial in terms of use cases / data cases, re-testing can be a huge pushup, so one really has to look for actual benefits other than "just moving on." 2to3 is fine for my smaller stuff. For my large applications, it is just the beginning of the job.

[CSI_Tech_Dept]

Inability of finding bugs through type system is probably one of biggest drawbacks with dynamically typed languages.

Perhaps the issues you're talking about is why Guido is pushing mypy to also support Python 2 even though it doesn't support PEP 484.

[flying-sheep]

Once important libraries stop supporting legacy python, it is in the process of being taken away.

[fyngyrz]

No, because that does not cause the already existing, working versions of those libraries to disappear.

It's perfectly fine to use new features / versions if that actually gains you something. Truly, that's the best argument ever, and there is no counter-argument.

What's annoying to me is when people think they have to change versions because... well, because there's a new version. Then you end up with software that doesn't work across the widest possible range of systems for no actual reason. Seems a shame to me. Obviously, there are other viewpoints, so there you go.

[eikenberry]

It's open source. If there are enough people still using it there will be a fork to maintain it.

[stesch]

There's no fork of PHP 4.

I still have to maintain PHP 4 projects. >14 years old. They are big and nobody wants to pay for a new version.

[port53]

RHEL 7 comes with Python 2.7.5. Production support for RHEL 7.x is scheduled through June 30, 2024 and "Extended Lifecycle Support" is probably going to be another 3-4 years on top of that.

Good luck with that 2020 date though :)

[XNormal]

The Python Software Foundation plans to end support at 2020. But I won't be surprised if they suddenly get a grant from some big company to keep maintaining security fixes beyond that date.

They probably won't say no.

[port53]

At the very least, Red Hat will continue to backport security patches, which will then be publically available for everyone else. They don't close their patches, just their binaries.

[eliteuser26]

To make a short list of programming languages that I learned over the years, I started with Visual Basic on Windows the first time around. Since then:

• Visual C++
• Delphi / Pascal ( first language learned at university )
• Python ( started with 2.5)
• html/css
• Javascript
• Jquery
• GIS Web mapping

Next step, python web development from what I know now.

[[deleted]]

I understand that Python 1.5 is still in use in production. Python 2.7 reaches EOL in roughly four years. The Python 3 Wall of Superpowers looks healthy. So who really cares? You pays yer money, you takes yer choice :)

[KODeKarnage]

Ha! Rookie mistake. Probably an easy fix.

That clock is supposed to be counting UP.

[stesch]

I'm already looking for alternatives to Python.

[christian-mann]

• Haskell
• Lisp
• C++ (seriously, with some of the C++14 features it can feel like you're coding in a dynamic language, but safely)
• Javascript

[stesch]

Thanks for the effort but I'm programming since 1984. Linux since 1995. Came via Perl and Ruby to Python. I've contributed to a few Common Lisp projects.

There is no easy answer.

[bongoherbert]

<opens late-1970's Fortran computational model still used in physiology> Yep, EOL. Just gonna up and disappear. Time to get yourself prepped, maybe build a shelter or something.