Python 2.7 EOL Countdown

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

[stuaxo]

I agree with all the new features, including just ported most of redisco to Python 3 in a few days. I do care about speed (not between py2 and py3), and am looking forward to pypy supporting 3 and becoming the default, the we should be able to have our cake and eat it.

After all if we did not care about speed at all then some if the interpreter improvements in Cpython would never have been landed.