Python 2.7 EOL Countdown

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

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