It's kind of disappointing that developers aren't self-aware enough to understand that they are essentially screwing themselves by not moving quickly in dropping "legacy" support.
"Python 3 will be available in 2008 but we understand that you won't use it for at least 5 years."
There's an entire class of developers who won't upgrade until they absolutely have to. There's also a class of administrator that won't upgrade their current PC browser from IE6-IE8 until they absolutely have to. Developers are basically screwing themselves by not drawing a firm line.
You know, when I am working on an existing project for a client that's allotted 15 hours a week to it, and I have to get actual features pushed out, I don't have time to check which of the 25+ dependencies I list are going to work in Python 3. Sure, maybe I can start a new project in Python 3, but there are enough existing projects to not be able to do this.
Also, even if I am starting an existing project, what if down the line I must use a library that's only available for Python 2? I am not going to rewrite something like that because it will cost my client money if I spend time on it.
The problem with Python 2 is that it's good enough. Python 3 is a huge improvement, yet until I can be reasonably sure that all libraries I am likely to use are available for both, Python 2 is the winner.
Having said that, any personal projects I have started recently have all used Python 3 and it's been great. I also try to make sure that any libraries I write work in both.
You are right that Python 2 is good enough, but I'd add a majestically large "yet", because that will change from one day to the other.
My primary machine runs Arch Linux, a distro that switched the /usr/bin/python link to python3 some months ago, thus generating a sort of "majority Python 3" environment. I myself, having been rather apathetic on the switchover before, have switched completely to Python 3 just because using Python 2.x has become a hassle.
Admittedly, I am in the fortunate position that all my active python projects could be moved over easily, once boost-python and matplotlib were solidly 3-ready. Other libaries are more problematic (looking at you, every Django-plugin out there).
My point is, Python 2 won't be good enough for long and for some of us it already isn't any more.
Citation needed. Even the devs aren't trying to sell it as much more than a clean up. Very little is actually qualitatively better, and there are some regressions also - for one, last time I looked it was still about 10% slower than Python 2 in most benchmarks.
I'm disturbed at how "citation needed" has become an argument. Since you are also making a claim (that it is not an improvement) don't you have an equal burden to provide citations? Are citations really what will make this argument?
It is also somewhat questionable to ask someone to prove a negative.
This isn't true at all. The negative is also often seen in the form of a null hypothesis. "There's someone in the fridge". "No, there isn't". Here is a case where we can prove a negative. Some negatives by their nature can't be proven, but as a blanket statement it's false.
You yourself mentioned that benchmarks were worse - this is proof of the negative, and you could have cited those benchmarks in your argument.
I think originally Python 3 was a big improvement. But with the back-porting its features to 2.x, the incremental benefit of upgrading has been steadily reduced.
Yes, I understand. I've worked in corporate America for a couple of decades. Anyway, I got downvoted for my comment so I'll leave it up to the community to figure out how to deprecate 2.x.
Hey, I get what you are saying. It's up to the developers to move to Python 3. I am just trying to say that there's a difference between a "make sure every bit of library code you write works in Python 3 first, then backport to Python 2 if necessary" and "every project must convert to Python 3 now". I am all for the former. If you write a library, write it in 3, then see if the unit tests pass in 2.
There is no such thing as a legacy programming language. Python 2 and Python 3 are two different, incompatible programming languages. The existence of Python 3 doesn't make Python 2 code legacy code.
Legacy doesn't mean unused, the definition of a legacy programming language is when no one is choosing it for new projects.
Python2 is going to be moving closer to this COBOL-status as people start coding for Python3 and Py2 support becomes more and more of an afterthought until they just stop bothering.
Even if that were true, which I would disagree that anyone writing a library from scratch today is ignoring Python3- over time it is an inevitability once the core dev team drops support for 2.7
For instance, I do some utility class software that needs to just work on RedHat/CentOS 6. Having to build Python 3 from source, or use SCL and mess with paths, and virtualenvs is simply not an option for my target user.
It's kind of disappointing that developers aren't self-aware enough to understand that they are essentially screwing themselves by not moving quickly in dropping "legacy" support.
I think the part that might be missing from your line of reasoning is context: For professionals and entrepreneurs programming isn't a hobby, it's a business.
The decision to stay with 2.x isn't about not being self-aware. It's about being serious about your business. Business has nothing to do with self-awareness. It would be irresponsible to send your organization down a path that could result in a huge setback.
If you are self-funded this could absolutely kill you. If you are in a competitive environment where time to market is crucial (who isn't) this could kill you. If you have investors who expect you to make responsible decisions, they could kill you.
How are you going to explain the decision to go to 3.x when the fertilizer hits the ventilator and you realize there are three choices in front of you:
1- Redo your entire codebase to migrate down to 2.x.
2- Launch a new project to rewrite the 2.x libraries you need.
This could take one week or one year.
3- Shut it down because you don't have enough cash to deal
with having made the wrong decision.
And, here's the kicker: You won't know until you hit that wall. Sure, you can do an initial dependencies survey. And hope you went deep enough. By definition, you will have no way to check dependencies you don't know about at the start of the project.
The bottom line is that in the context of a real business --not a hobby-- sticking with 2.x is probably the only responsible choice for a huge number of organizations. I really think the Python leaders made a mistake in not coming up with a smooth on-ramp onto the various ideas in 3.x. I do understand that some things need to be broken sometimes. In the real world you can only break so much of a codebase before people avoid it like the plague.
Here's the other reality: The customer doesn't give a damn whether you are using 2.x, 3.x, Python, Lisp, PHP or assembler. They buy your product or use your service because of the value they derive from it. For the vast majority of businesses and customers this has nothing whatsoever to do with the technology choices you make behind the scenes. If this fact isn't obvious, study the history of a number of prominent startups and you'll find support for this idea.
It's easy to fall back on engineering think and forget reality. I do it all the time. Over the years I've become better at avoiding thinking like that. Like wanting to build a product without doing market research and, a year later, finding out the hard way nobody wants it.
I'm not criticizing you here. I am simply pointing out something we all do from time to time.
I'm willing to be the vast majority of Python code in existence right now is academic in nature.
Most academics--from an engineering standpoint, mind!--write really shitty and garbage code, under deadline to submit yet another paper for the mill.
There is no surprise that they would be unable/unwilling to appreciate the long-term damage they inflict on themselves when using what should be deprecated features.
Meanwhile, Rubyists and Node rockstars are laughing all the way to the bank, and the Erlang bros are already there.
EDIT:
Okay, fine, downvote, but at least mention which part of that statement you disagree with.
While I won't speculate as to why people downvoted (and I didnt downvote), I personally would disagree with your first assertion. Python is used in production all over the place, particularly for web-facing applications (obviously all Django sites but also large sites like Google) but also applications like Dropbox.
Comments
It's kind of disappointing that developers aren't self-aware enough to understand that they are essentially screwing themselves by not moving quickly in dropping "legacy" support.
"Python 3 will be available in 2008 but we understand that you won't use it for at least 5 years."
There's an entire class of developers who won't upgrade until they absolutely have to. There's also a class of administrator that won't upgrade their current PC browser from IE6-IE8 until they absolutely have to. Developers are basically screwing themselves by not drawing a firm line.
You know, when I am working on an existing project for a client that's allotted 15 hours a week to it, and I have to get actual features pushed out, I don't have time to check which of the 25+ dependencies I list are going to work in Python 3. Sure, maybe I can start a new project in Python 3, but there are enough existing projects to not be able to do this.
Also, even if I am starting an existing project, what if down the line I must use a library that's only available for Python 2? I am not going to rewrite something like that because it will cost my client money if I spend time on it.
The problem with Python 2 is that it's good enough. Python 3 is a huge improvement, yet until I can be reasonably sure that all libraries I am likely to use are available for both, Python 2 is the winner.
Having said that, any personal projects I have started recently have all used Python 3 and it's been great. I also try to make sure that any libraries I write work in both.
You are right that Python 2 is good enough, but I'd add a majestically large "yet", because that will change from one day to the other.
My primary machine runs Arch Linux, a distro that switched the /usr/bin/python link to python3 some months ago, thus generating a sort of "majority Python 3" environment. I myself, having been rather apathetic on the switchover before, have switched completely to Python 3 just because using Python 2.x has become a hassle.
Admittedly, I am in the fortunate position that all my active python projects could be moved over easily, once boost-python and matplotlib were solidly 3-ready. Other libaries are more problematic (looking at you, every Django-plugin out there).
My point is, Python 2 won't be good enough for long and for some of us it already isn't any more.
Arch Linux has been python3 by default for several years now. I remember it was a very controversial decision at the time.
Citation needed. Even the devs aren't trying to sell it as much more than a clean up. Very little is actually qualitatively better, and there are some regressions also - for one, last time I looked it was still about 10% slower than Python 2 in most benchmarks.
I'm disturbed at how "citation needed" has become an argument. Since you are also making a claim (that it is not an improvement) don't you have an equal burden to provide citations? Are citations really what will make this argument?
The primary burden is the one stating the original argument. It is also somewhat questionable to ask someone to prove a negative.
considering that 3 is 50% more than 2, I'd say the negative is that it ISN'T a "huge" improvement.
(only a little kidding).
It is also somewhat questionable to ask someone to prove a negative.
This isn't true at all. The negative is also often seen in the form of a null hypothesis. "There's someone in the fridge". "No, there isn't". Here is a case where we can prove a negative. Some negatives by their nature can't be proven, but as a blanket statement it's false.
You yourself mentioned that benchmarks were worse - this is proof of the negative, and you could have cited those benchmarks in your argument.
I think originally Python 3 was a big improvement. But with the back-porting its features to 2.x, the incremental benefit of upgrading has been steadily reduced.
Nothing's been back-ported to Python 2 in nearly 4 years now. 2.7 came out in July 2010.
It's not a huge improvement to me, that's why I don't use it.
Yes, I understand. I've worked in corporate America for a couple of decades. Anyway, I got downvoted for my comment so I'll leave it up to the community to figure out how to deprecate 2.x.
Hey, I get what you are saying. It's up to the developers to move to Python 3. I am just trying to say that there's a difference between a "make sure every bit of library code you write works in Python 3 first, then backport to Python 2 if necessary" and "every project must convert to Python 3 now". I am all for the former. If you write a library, write it in 3, then see if the unit tests pass in 2.
It's an improvement, but it's not huge. It's a better language, but it's still the Python we all know and love without a couple warts.
There is no such thing as a legacy programming language. Python 2 and Python 3 are two different, incompatible programming languages. The existence of Python 3 doesn't make Python 2 code legacy code.
Legacy doesn't mean unused, the definition of a legacy programming language is when no one is choosing it for new projects. Python2 is going to be moving closer to this COBOL-status as people start coding for Python3 and Py2 support becomes more and more of an afterthought until they just stop bothering.
But most new Python projects get started in Python2. It's Python3 that is legacy language by your definition.
Even if that were true, which I would disagree that anyone writing a library from scratch today is ignoring Python3- over time it is an inevitability once the core dev team drops support for 2.7
Its not always the developer.
For instance, I do some utility class software that needs to just work on RedHat/CentOS 6. Having to build Python 3 from source, or use SCL and mess with paths, and virtualenvs is simply not an option for my target user.
I think the part that might be missing from your line of reasoning is context: For professionals and entrepreneurs programming isn't a hobby, it's a business.
The decision to stay with 2.x isn't about not being self-aware. It's about being serious about your business. Business has nothing to do with self-awareness. It would be irresponsible to send your organization down a path that could result in a huge setback.
If you are self-funded this could absolutely kill you. If you are in a competitive environment where time to market is crucial (who isn't) this could kill you. If you have investors who expect you to make responsible decisions, they could kill you.
How are you going to explain the decision to go to 3.x when the fertilizer hits the ventilator and you realize there are three choices in front of you:
And, here's the kicker: You won't know until you hit that wall. Sure, you can do an initial dependencies survey. And hope you went deep enough. By definition, you will have no way to check dependencies you don't know about at the start of the project.The bottom line is that in the context of a real business --not a hobby-- sticking with 2.x is probably the only responsible choice for a huge number of organizations. I really think the Python leaders made a mistake in not coming up with a smooth on-ramp onto the various ideas in 3.x. I do understand that some things need to be broken sometimes. In the real world you can only break so much of a codebase before people avoid it like the plague.
Here's the other reality: The customer doesn't give a damn whether you are using 2.x, 3.x, Python, Lisp, PHP or assembler. They buy your product or use your service because of the value they derive from it. For the vast majority of businesses and customers this has nothing whatsoever to do with the technology choices you make behind the scenes. If this fact isn't obvious, study the history of a number of prominent startups and you'll find support for this idea.
It's easy to fall back on engineering think and forget reality. I do it all the time. Over the years I've become better at avoiding thinking like that. Like wanting to build a product without doing market research and, a year later, finding out the hard way nobody wants it.
I'm not criticizing you here. I am simply pointing out something we all do from time to time.
Who exactly am I screwing by sticking with python 2? It's certainly not me or my employers.
Maybe if van Rossum had produced a compelling reason to switch (like, for example, removing the GIL) I would have gone over by now.
The maintainers of Python (and libraries) are screwing themselves. You missed the point. Now they have to support two versions.
I'm willing to be the vast majority of Python code in existence right now is academic in nature.
Most academics--from an engineering standpoint, mind!--write really shitty and garbage code, under deadline to submit yet another paper for the mill.
There is no surprise that they would be unable/unwilling to appreciate the long-term damage they inflict on themselves when using what should be deprecated features.
Meanwhile, Rubyists and Node rockstars are laughing all the way to the bank, and the Erlang bros are already there.
EDIT:
Okay, fine, downvote, but at least mention which part of that statement you disagree with.
While I won't speculate as to why people downvoted (and I didnt downvote), I personally would disagree with your first assertion. Python is used in production all over the place, particularly for web-facing applications (obviously all Django sites but also large sites like Google) but also applications like Dropbox.
"Okay, fine, downvote, but at least mention which part of that statement you disagree with." rockstars... bros...