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...
2.7 and either 3.2 or 3.3+ is probably the best way to go at the moment.
If you're absolutely sure that you'll never need a new dependency for your project in future which is Python 2 only - then you could go for Python 3 only. However for what I do I can't risk dropping 2.7 support incase I need use a library at a later date which doesn't support Python 3.
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.