I may have agreed with this a year or two ago. Not now though. The situation is way better than it used to be, and only improving.
Developing a new module to run on both Python 2 and Python 3 is also much less of a pain than it used to be. Particularly if you follow the advice on (http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/). It does make your code less beautiful than a pure Python 3 code base, but that is the price you pay for compatibility.
My biggest porting headache was adding Python 3 support to PyFilesystem. It was tricky because this library is an abstraction layer for files, which work quite differently in Python 3, and we didn't want to have to write everything from scratch. I have ported another, much larger project, in a day. It was tedious work, but no major issues.
But these problems only effect library developers. If you're building an application, just use Python 3. Most libraries have Python 3 support, and most of the ones that don't are probably not actively maintained any more.
Any tips on convincing a coworker that starting a brand new app from scratch in 2.7 is not as good a choice as starting in 3.*? He's absolutely convinced that 2.7 is vastly superior and that 3.* isn't worth trying to support because so many libraries don't have 3.* compliant versions, and that "because we have 2.7 running in production now, why complicate things by adding another version?"
I'm not familiar enough with the Python ecosystem to really refute these points, but I can't imagine that starting a brand new project in not-the-latest-stable-version-of-the-language is the best choice, and I was under the impression that virtualenv was effective at managing multiple python versions for different applications.
His current goal is to get everyone to write 2.7 and 3.* compliant code so that we can eventually make the switch. I don't really think a wholesale switch is ever feasible, but he won't listen to that logic, either...
That is both disappointing and a bit depressing. I don't keep up with Python (mostly because my work keeps me in JS or non-Python backends 100% of the time, so far), so I wasn't clear on the reasons why Python 3 is generally looked down upon. I should really look at the debate a bit more closely so I can at least understand where the language is going...
It also isn't true. It's an extraordinary claim that this random person on the Internet has better insight into the proper evolution of Python than its own creator. Of course, they offer no evidence to back up this assertion.
All this is is people who are simply resistant to change. In the Delphi world its corporate maintainer wants to introduce memory management, zero-based immutable strings and other modern developments to both attract new users and make developing for mobile devices easier. People began complaining, and over and over again they claimed that this was going to be done "for no reason at all". This was in spite of a massive white paper being produced that explained why they wanted to make the changes. These same people claimed that Java had these features "for no reason" and it took all of 10 seconds to find a Java white paper also explaining all the reasons these features exist in the language.
It's the same thing with the Python holdouts. "They broke everyone's code - and for bad [unspecified] reasons" is patently untrue. Guido and others painstakingly explained those reasons and the claimant isn't offering any rebuttal.
so I wasn't clear on the reasons why Python 3 is generally looked down upon.
Inertia. People just don't want to have to do anything to port code. No language has ever been as accomodating as Guido has been and they still want Python 2.8, 2.9, 2.999995, etc.
It has to work the other way, however, too. Armin, in particular, has created some farily detailed criticisms of how Python 3 is structurally broken with respect to IO boundaries. They might have been delivered more kindly, as it can be grating to have someone pound on your work over and over in semiblue language. But regardless, the issues do exist, and these aren't things that can be just kinda bugfixed or something; a real solution would require bw incompatible changes and buy-in from lots of people. And if there are folks ignoring the rationales coming from Guido, there are just as many effectively ignoring (or at least minimizing) the rationales coming out of the folks doing the criticisms of Python 3. There are of course good reasons to do this; to make yet another very-bw-incompat release of Python would be very costly, and very might kill the language faster than leaving the structural deficiencies in. But that doesn't mean the issues don't exist, and that such a bw-incompat release might not be the right thing to do.
In that case, it's both disappointing and a bit depressing that there's so much strife in the community and FUD being spread about upgrading to 3.*. The responses to my first reply in this context have been evidence enough of that...
Python is a decent enough language. I really wish the community and lead devs would unify behind something, though, whatever it happens to be. The divergence is just more overhead to have to understand before spinning up this new project that I'm sure I'm going to inherit somehow.
Thanks for the longer response. Any chance you have those white papers bookmarked?
That is why I always ask for cited sources. It's hard to evaluate all of the data when I don't write much Python myself yet, but it seems that the community dislikes 3.* and the language devs work predominantly on 3.*. I suppose part of the reason I was initially opposed to my coworker's logic is his adamance when the only supporting claims he could make were "some big library authors don't like it", which isn't exactly a great argument and certainly not enough to warrant the level of confidence he was showing. His phrasing and argument were weak enough to make me question the underlying logic, which spawned this whole discussion. It seems that, in the end, he was right, but at least now I can support that argument with more data than he did.
It seems the path of least resistance for us here is 2.7 anyway so it looks like that's the path we'll be taking.
69
u/willm May 26 '14
I may have agreed with this a year or two ago. Not now though. The situation is way better than it used to be, and only improving.
Developing a new module to run on both Python 2 and Python 3 is also much less of a pain than it used to be. Particularly if you follow the advice on (http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/). It does make your code less beautiful than a pure Python 3 code base, but that is the price you pay for compatibility.
My biggest porting headache was adding Python 3 support to PyFilesystem. It was tricky because this library is an abstraction layer for files, which work quite differently in Python 3, and we didn't want to have to write everything from scratch. I have ported another, much larger project, in a day. It was tedious work, but no major issues.
But these problems only effect library developers. If you're building an application, just use Python 3. Most libraries have Python 3 support, and most of the ones that don't are probably not actively maintained any more.