Fedora Linux will switch to Python 3 by default
fedoraproject.org
fedoraproject.org
Distros that use Python 3 by default (such as Arch and Gentoo) still allow for Python 2 to work side-by-side with Python 3. Proper separation using virtualenvs works seamlessly, and there's no problem at all to work simultaneously on Py2 and Py3 projects.
Then after reading your comment, I remembered that my complete switchover was triggered by the default version switch in my primary machine's distro (Arch).
So indeed, these things do matter for real-world adoption of Python 3.
From the two sections in here it appears that Fedora will stick with `python` pointing to Py2, so that's good news.
Arch switched to python3 as the default "/usr/bin/python" with no way to change it because of their persistence on following the upstream. They payed the price by having to hunt down and modify all the python2 scripts.
IMHO confusing these roles and providing, or expecting one install of a language to fit both simultaneously has been something that's irritated me about Unix-like OSes for a long time, much as I love them.
Yes I know there are plenty of tools for installing dev versions of tools side by side with the system components. IMHO doing so should be the default assumption unless you really are developing system scripts or scripts that you explicitly expect to be limited in scope to that OS.
Next time I do some Python development (other than system admin scripts) I will be using Python 3.4. And I will likely also create a self-contained build of that as well.
Can someone with knowledge of python ecosystem explain what took a major distro so long, given that you could run different versions of python in parallel (or couldn't you?) for some of big pro software that needs the old version? [1] - http://python.org/download/releases/3.0/
python 3.2.5 there (and not so later) by default and you can run oldest versions in parallel also
For ubuntu actual is window manager and good alternative desktop with usability, for Fedora maybe C development, for gentoo it is portage of course and their package manager powered by python.
"We (i.e. the Python core developers) predicted when Python 3.0 was released that it would take about 5 years for 3.x to become the "default" choice for new projects over the 2.x series."
He suggests the 5 year timeline begins in June 2009 with the release of 3.1 (since 3.0 still had many bugs) - so that means there is a little more than half a year left for it to become the default, if the prediction holds true.
The rest of his post goes into the issues in adopting Python 3.x.
[0]: http://programmers.stackexchange.com/questions/63859/why-do-...
Welcome to the real world.
In the case of Python 3, a neat thing library developers can do is write code that is both valid for Python 2 and Python 3. The six[0] library is a wrapper for making code compatible with both versions. There are tools like 2to3[1] and 3to2[2] that convert code from one version to another. They're not perfect but do catch the most common differences. Such things help with making the change.
However it is the availability (or more exactly lack of) of famous and widely used libraries that hinder or speed up the adoption. For example, Django recently started offering a Python 3 version[0]. Numpy and Scipy support it since around 2011 only.
0: http://pythonhosted.org/six
1: http://docs.python.org/2/library/2to3.html
2: https://wiki.python.org/moin/3to2
3: "Porting to Python 3" htthttp://pythonhosted.org/sixps://docs.djangoproject.com/en/de...
>Django 1.5 is the first version of Django to support Python 3. The same code runs both on Python 2 (≥ 2.6.5) and Python 3 (≥ 3.2), thanks to the six compatibility layer.
"Django's future, and Python 3" https://www.djangoproject.com/weblog/2012/mar/13/py3k/
At least Python has a sane versioning scheme, where breaking compatibility increments the major version number or is a bug.
It's also still going to be a while before Python 2 is actually removed, and while both are available the `python` executable will continue to point to Python 2.
If you don't ask for Python at the moment, you'll still get in your base install, because the system uses it. You get Python 2. In the future, you'll get Python 3 instead.
Python 3 has been packaged and co-installable in Fedora for many years, and likewise a large number of Python 3 libraries are also packaged, and Fedora even put in quite a bunch of effort into tracking and increasing that number via porting efforts. And thanks to all of that, things are now getting ready to abandon Python 2 for the most core parts of the system itself.
So it's not like those six were spent idle, rather they were in the process of "adopting it" for much of those six years, and this is simply another milestone in that process.
If you were a user of the system and wanted to run something against Python 3, you could do that for a long time now. I've written plenty of Python 3 on Fedora systems using nothing but system packages.
I suspect Archlinux's job was easy, because they had fewer system tools that utilized python. For example, Pacman (Arch's package manager) is written in C, whereas Yum (Fedora's package manager) is written in Python. Fedora also has other components that use python (the firewall frontend, some build/install/setup scripts), and "switching" to python3 involves porting over all of that.
Otherwise no big news, since all other major distros are switching to default python 3 too.
I just wish Python 3 didn't benchmark so much slower than Python 2 in some of my use cases (though I still aim for compatibility with it).
Couple of relevant search results:
http://stackoverflow.com/questions/14911122/same-code-slower...
http://pythonadventures.wordpress.com/2013/08/15/python-3-is...
Has anyone else experienced this?
Do a benchmark after the file has been opened with an explicit encoding, to see if I'm right. If the files already been decoded, there shouldn't be as big a difference.
[0]: E.g., 3.3 adds a more efficient encoding for ASCII-subset unicode strings: http://docs.python.org/3/whatsnew/3.3.html#performance-and-r...
This will be interesting.
Who's suggesting that you change the system default? If you want to make your python scripts run on a certain python version, set their shebang accordingly. Changing the default interpreter for system scripts because you want your scripts to run on a different version is crazy.
If your lamp is too bright, do you swap the transformer supplying the whole street's mains electricity supply for one with a different voltage and hope your neighbour's computer doesn't break, or do you turn your lamp down?
/usr/bin/python should remain symlinked to python2, and never python3: http://www.python.org/dev/peps/pep-0394/
But in any case, all scripts should reference the actual required version in the #! line.
"For the time being, it is recommended that python should refer to python2 (however, some distributions have already chosen otherwise; see the Rationale and Migration Notes below)."
#!/usr/bin/python
#!/usr/bin/python2.6
As long as that's done, and the packaging is done right, there shouldn't be any major issues for the vast majority of programs.
I'm already doing that, the difference is that "python" for me is Python 2 and I have to run "python3" to use Python 3. Other than that, I can't see any problem. You can install packages for both versions, the distros usually add a number (ie. python-django, python3-django).
In the long run, switching to python3 will be better.
So, yes, this likely means some future version of RHEL (and thus derivatives like CentOS and Scientific Linux) will also make the "switch" over to python3. Considering the turnaround time for RHEL versions (and how Fedora is still slow on the uptake of python3), I wouldn't expect this to happen anytime soon though.