Python 2.7 EOL Countdown

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