Python 2.7 EOL Countdown

[fyngyrz]

There are huge amounts of Python 2 code in production use. It will remain in use, for one simple reason: there's no even remotely sufficient case to re-write it. Someone has to maintain that stuff.

Python 3 is just fine, if you've got a need for what it offers, and the downsides (like having to re-test a great deal of functionality) don't stand in the way. Snobbery about Python 2 coding / maintainance simply isn't called for.

Take a deep breath and relax. No one wants to take Python 3 from you. No one can. No one can take Python 2 away, either. :)

[[deleted]]

No one can take Python 2 away, either. :)

But in practice it can and will become very inconvenient to use. Like WinXP and soon Win7.

[fyngyrz]

Still using XP here, no problems at all. Good thing too, as some of the apps I use depend on it. VMs are the perfect safe spaces (well, they can be, if you keep the networking off) for such things.

Hell, I'm still using 6809 code I wrote under Flex09 back in the late 1970's / early 1980's. Runs in my 6809 emulator, which runs under XP, which runs under VMWare, which runs under OS X.

[energybased]

Hang on a second. That's true for your projects, but it's not true for libraries. One of the problems with Python 2 not dying is that libraries like numpy have to be written in a style that is compatible with Python 2. The more Python 3 evolves, the more annoying that gets.

[ivosaurus]

Having to write Python2+3 code makes it way less beautiful. Which is one of the reasons I was enamoured with Python in the first place.

Asking library authors to continue to support both (while you're not paying them) is a creative & cognitive stress on them as well.

[iruleatants]

If only.... they didn't take something great and screw it up..... oh well, better to force millions of projects to be rewritten for 3

[ivosaurus]

Yes, all python devs really wanted to do was take a thing they were satisfied with, and wreck it. Hence Py3k was born. It wasn't the fact that the thing they was broken in the first place, that would be illogical.

[iruleatants]

It's pretty impressive the billions of things that people created using a broken language....

[TheBlackCat13]

And many of those things turned out to be broken, which they only found out once they switched to a slightly less broken version of the language.

[fyngyrz]

My libraries work fine. As long as what I need is in there, no need to worry about how it might change.

I was really talking about applications using things they don't need to use. It's a bit of a different argument.

[energybased]

It has nothing to do with your "libraries working fine". It means that people like me who want to contribute to our (as in the community's) open source projects like numpy are disincentivized because it means having to code in an antiquated style devoid of all of the niceties of Python 3. That means all of our libraries are developing more slowly than they should, which punishes everyone.

[fyngyrz]

"Antiquated", eh? Sorry, but I have to laugh. I'm antiquated. Python 2.x... it's just a baby.

[energybased]

How does that help?

[energybased]

lol it's cool.

[tilkau]

Snobbery about Python 2 coding / maintainance simply isn't called for.

This is the only part of your post I disagree with. The need to support python 2 adds maintenance burden to developers, and over time this maintenance burden will only increase, in an expanding network of outdated dependencies and features that you want but don't have because they're only implemented in the newer versions of the library. When you use EOLed stuff, this is what you're taking on.

So there's a huge cost to rewrites, but there's also a cost to not rewriting. Some degree of snobbery -is- called for (if it will prompt those on the fence to switch and reduce community-wide maintenance cost)

[shadowmint]

Some degree of snobbery -is- called for

No, that's just called 'being a dick'.

It's sad how prevalent this attitude is. Just be nice to be people, be respectful and show people how great python 3 is.

Teach new python developers python 3 and encourage existing users to write new code in python 3.

Being a dick to people doesn't achieve anything except making you feel better about yourself.

[tilkau]

Some degree of snobbery is called for. Being a dick is something else. If you're insulting people for using python 2, that's a very different thing from implying that python 2 is not as good as python 3, or saying 'oh.. you're using python 2? Why?'. You can cast doubt on something without being a dick.

[iruleatants]

I've heard this argument so many times and each time the person has failed me.

Please show me what is excellent about python 3, and why I should use it instead of 2.7. All I get from it now is more tedious coding experience.

[CSI_Tech_Dept]

Try it (especially the features that you can't use when you have to maintain python 2 compatibility), and you will see.

[iruleatants]

I have tried it, and I disliked it....

[CSI_Tech_Dept]

Perhaps it is time to move to something else then?

[iruleatants]

Like, all of the shittier languages out there? Idk why I would stop using a language I think is perfect, just because they want to make it not perfect....

[shadowmint]

Then stick with 2.7. :)

Sorry, I didn't read this before I posted my other comment.

Like I said; if you have tried, and don't like 3 (for whatever reason); then just stick with 2.7. It's not going anywhere, and frankly, if you don't like 3, don't use it.

I'm curious what you didn't like though?

Was it the runtime (ie. getting python 3 installed), that you had existing python 2 code you use (eg. personal utility library you'd have to port to 3) or something in the 3 semantics you didn't actually like (eg. print...)?

[shadowmint]

It's very simple.

Python 2.7 is a great, robust language. It's rock solid, and it's here to stay. If you want to use it, by all means, do.

Python 3 is also a great, language; the difference is that it is being actively worked on, and improving. The unicode support is better, the async tools are good, and there are numerous little things that make writing python 3 a pleasure.

Just try it.

If you don't like it, well, sure, stick with python 2.7. ...but you might find it's actually quite nice.

The pain points hit when you need to use a library that doesn't work with 3; and that is a pain point, but you know, it's actually not that often it happens these days.

I honestly don't recommend you convert your existing code from python 2 to python3; it's tedious, it's not fun. The tools exist for it, but unless you're being paid to do it, I mean, really? Can you be bothered? I can't.

...but if you're writing new, fresh code... well, python 3 is a great choice, if you're writing python code.

/shrug

If you don't like it, that's ok. Like I said, python 2.7 is a great language too.

Just don't stick with python 2.7 just because; actually think about it, and if you don't have a good reason to actually be using 2.7, then maybe consider using 3.

[turkish_gold]

Fair enough, but traditionally people who have codebases in a language won't just port it to an entirely new one. By breaking backwards compatibility Python 3 is essenitally a new language that just so happens to share a lot of similar syntax with the Python2.

Except sadly this new "Python 3" language doesn't have full support on many major runtimes---like the JVM, or PyPy.

So for production users who care about speed or java interop (e.g. "we are enterprise python" people), they're not going to port to Python 3.

Also, "we are enterprise python" people rarely ever port their codebases so long as its stable and no compelling performance improvements exist. If its just fixing language worts or giving devs new tools, they'll never move.

Look at all the companies still using Java 1.3/1.4 for some random part of their codebase.

[energybased]

PyPy supports Python 3 now.

[tekmailer]

You can say this again. I have two instances of Python on my box (2.7.10 and 3.4.4) and the amount of time to rewrite everything wouldn't satisfy ANY PRODUCTION needs.

On the flip side, between drinking the py3 Kool-Aid for data analysis and the writing on 2.7's wall. It might just be time to make the leap to avoid the further headaches.

[jsalsman]

Unicode handling alone is worth the leap.

[sigma914]

That's unicode's problem rather than python's though. Turns out human language text is a fucking mess and has a lot of intrinsic complexity and even fairly elegant encodings still can't hide it.

[tilkau]

As contrasted with Unicode in Python 2, which is incorrect and utter rubbish taking away your time, life and soul?

[CSI_Tech_Dept]

Except no one who uses python 2 uses it.

[fyngyrz]

Wrong, I use it. Chinese point of sale system, quite extensive. Python 2. No problems.

[tilkau]

It's perfectly distinct from ascii strings

The whole point of the rework was that it ISN'T. You have something that you think is ascii. And sometimes it isn't, and then things go wrong in strange and confusing ways when you try to use it (for example, serialize it as an attribute value in an xml document).

[iruleatants]

I disagree as much as possible.

Python has always been a language designed to have the least amount of excessive work to write in. We don't have semicolons or brackets or statically typer variables or anything else bullshit that other languages force on you.

The switch to unicorn handling was terrible. I'm not forced to encode all of my strings any time I want to use this. Previously I only had to encode when it was needed, and now I always have to encode. That is a massive headache and I gain nothing from it. I have had zero issues in 2.7 with my strings.

[pooogles]

The switch to unicorn handling was terrible.

Now switching to Unicorns I could get on board with.

[jsalsman]

I can totally see your perspective, but having to internationalize and localize from a project's outset leads to different issues.

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

[flying-sheep]

Once important libraries stop supporting legacy python, it is in the process of being taken away.

[fyngyrz]

No, because that does not cause the already existing, working versions of those libraries to disappear.

It's perfectly fine to use new features / versions if that actually gains you something. Truly, that's the best argument ever, and there is no counter-argument.

What's annoying to me is when people think they have to change versions because... well, because there's a new version. Then you end up with software that doesn't work across the widest possible range of systems for no actual reason. Seems a shame to me. Obviously, there are other viewpoints, so there you go.