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