Entering edit mode
10.4 years ago
Eric Normandeau
11k
Hi,
I have postponed switching to Python 3 for a few years now for the reasons listed below.
Pros of Python 2
- Used by a lot of people
- All my code is in Python 2
- Code available online is often in Python 2
- Some time ago, Biopython did not work in Python 3
Pros of Python 3
- Its more recent?
- Any good reason?
So, it is the time of the year when I am thinking about making the switch again and, as an added piece of data for my decision, I would like to know:
- What version of Python are you using for your bioinformatic work?
- What are the benefits of using Python 3?
Thanks!
Basically, there is a lot of people still using 2.7 because the scientific libraries used to be not compatible with 3.x. Relevant:
this video piqued my interest and installed python3 then went ahead and tried to install a few packages that I would like to use - many failed with cryptic
ascii codecerrors, none of which indicated what the problem was (obviously it has to be some sort of Python 3 incompatibility but it confuses me even as an experienced python programmer). Of all errors why an UnicodeDecodeError ... it should just have a built in heuristics that tells us that the code is for 2.7 ... the current behavior is very confusing.Thus I am afraid that the situation is still pretty dire for Python 3, numpy and matplotlib may run but many others will not. This may not be a popular opininon but I still suspect that many of neat features will be eventually backported into Python 2.7 if not by the main developers then by others as libraries.
I think Python 2.7 will remain the dominant version of Python for many years - and I would still recommend a beginner to stick with 2.7
There was an old thread three and a half years ago: When should we develop biopython that support python 3.X？ it saddens me that three years later I am pretty much of the same opinion as back then. Not worth the trouble if you need to get work done.
Any chance you can share the names of packages that failed?
relevant: https://wiki.python.org/moin/Python2orPython3
This has come up as a support issue for Python scripts we distribute. I don't think we will move from Python to Python3 for some time. It just isn't used as much, and it is basically its own language, for all the porting and testing work that is required to migrate code. I still have yet read a compelling reason to switch. Is I/O any faster, for instance? (Can't imagine it would be deliberately made even slower!)
This article may be of interest: http://jakevdp.github.io/blog/2013/01/03/will-scientists-ever-move-to-python-3/
Ok, I'm curious. Can you give me one simple example where you can't port code easily to run in 2.7 and 3.3? And quite frankly, I think the article misses the point: why does it argue to need a 3to2 conversion tool if 2to3 conversion "is an easy ask" (paraphrasing).
the rationale for
3to2is that you want to be able to reach people that cannot or won't switch to python 3.I consider it a very salient point that I never thought of before, - anyone that wants to support both python 2 and 3 will have to keep using python 2 to do so, thus keeps even more people from switching to python 3.
Except that it's not true. You can (easily) write code that is valid in 2.7 and 3.x.
Ok but wouldn't that mean that you are coding in Python 2.7? Basically not using any feature that Python 3 has? The point of a 3to2 tool is to allow you to adopt the new constructs in Python 3, enjoy the new stuff Python 3 has yet still be able to run in on Python 2.
This is exactly why people should start ensuring python3 compatibility of their scripts now. Many features are backported - only very few are python3 only, but that will change. Take for instance replacing
print xbyprint(x): both are valid python2 but only the latter is valid python3. Similar case with integer division, where1/2 == 0in python2 unless you specifyfrom __future__ import division. The same statement is a no-op in python3. This way it doesn't matter what you use now, but you are ready for new features in python3 (and this without needing converters). Only ensuring compatibility with python2 will be a pain later (and relying on automatic converters is a bad idea in general).Interesting datapoint I noted today. Barry Warsaw is a core python developer, he was a release manager for a few of python 3.* versions. He is also the author of the python based GNU mailman which had its last stable release on 23-Nov-2013. Suprisingly GNU mailman does not run on Python 3.
I am mainly still using 2. But I have 3 installed. With virtualenv, versions are not really an issue.
I use Py3 for all of my coding / pipelining / data wrangling. A year ago there were a number of common libraries that weren't ported, but the vast majority of the large libraries that people use on a day-to-day basis are now done (iPython, Matplotlib, Numpy, PyPy, Pandas, etc). Not all are perfect, but they're an awful lot closer. There are still smaller libraries (generally made by individuals) that aren't moved over, but with few exceptions, you need to alter very few lines after 2to3 has done its work to get something going with 3. The biggest pain for me was recently getting a library with a lot of C extensions going, as the API for that has changed quite a bit.