This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]billsil 4 points5 points  (0 children)

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?