Only 9 years after the release of python 3. Maybe in another 9 years I can stop having to install python 2 + a bajillion libs on my system along with python 3.
I think it’s more likely that in 9 years there won’t be a python 3, or possibly a python 2. This switch has been so painful and sucked so much air out of the community that it is putting the future of python itself into jeopardy.
This would be terrible, if it were true.
I was programmatically going through a massive list of python packages in use at our place, and it turned out that only a few of those packages was incompatible with Python 3. And for those, many were unmaintained (with a maintained, python 2 and 3 compatible fork available, so basically packages you wouldn’t want in your dependencies anyway). Basically I ended up with almost no incompatible dependencies.
Sure enough, 9 years ago it was a bumpy ride. But the last 2-3 years are not like this at all for me. So when you are writing such a comment, I would like to know if you can bring up issues with regards to the Python 2-3 split that you experienced in the past 2 years. Because talking about the Python 3.0 release is so 2008.
Sure 8 years sounds long, but let’s have a look at the timeline. Python 3.0 was released in 2008. Python 2.7 in 2010. Python 3.4 (released in 2014) is the first release, that I would say could compete with Python 2.7 in terms of stability and backwards compatibility. We are now in 2017 and debian-stable now features Python 3.4. So now is the time that Python 3 adoption can actually start. I would assume that Python 2.7 got adopted also not in 2010, but ~2013 roughly speaking. So, we are experiencing a delay here in adoption, but the delay is much shorter, than 8 years. We could have wished for it to show up 1-2 release cycles earlier (that would be 2-4 years), but really, the python devs had our back here, releasing 2.7.10 in 2015, many linux distributions ship python 2 and python3 in parallel, making a migration also much easier.
I am not a Python fanboy, but a user who enjoys the ecosystem. And I don’t feel like Python 3 is a huge problem in the community. [*]
Python 3 brings features to the table that just make library development better. Keyword-only arguments are just one such example that library authors can use to make minor changes to the API not break user code by accident. The Python releases have also seen a bunch of development from 3.4 to 3.6 that you can’t benefit from if you use Python 2. This starts with the addition of missing functionality in the standard libraries, better syntax, exception reraising made easier, ordered-by-default dictionaries, async, etc.
[*] maybe those who have seen this as a problem have left longtime ago for Go. But If you did port your application from Python 2 to Go, you don’t really have a point criticising the steps needed to Port an application to Python 3.2 (or even easier to Python 3.4).
many linux distributions ship python 2 and python3 in parallel, making a migration also much easier.
I don’t disagree with your general point, but to me, this bit is a bug, not a feature. I hate that I end up with two versions of Python, two versions of iPython, etc. It’s annoying and it forces me to think too much about which version I’m using. This also means that I’m much more likely to just use Python 2 because that’s the only that’s just called “python”, so things will work with it and I don’t have to remember to add a “3” to every command I run (ipython3, pip3, and so on).
Hmm, maybe your workflow is different from mine. I usually create a virtual environment virtualenv --python=python3.4 myvenv or virtualenv --python=python2.7 myvenv and then the given python executable is the default python after
virtualenv --python=python3.4 myvenv
virtualenv --python=python2.7 myvenv
virtualenv --python=python3.4 myvenv
yields Python 3