Fedora Linux will switch to Python 3 by default(fedoraproject.org)
fedoraproject.org
Fedora Linux will switch to Python 3 by default
https://fedoraproject.org/wiki/Changes/Python_3_as_Default
17 comments
When I read the headline, my first thought was: "Well, _I_ alread switched over some time ago."
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.
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.
This is untrue about Arch, but true about Gentoo and seemingly will be about Fedora. Your experience with "Py3 default distros" has a bit to do with what version `python` points to. You certainly can get by with virtualenv all over and / or setuptools rewriting shebang lines but it's less convenient.
From the two sections in here it appears that Fedora will stick with `python` pointing to Py2, so that's good news.
From the two sections in here it appears that Fedora will stick with `python` pointing to Py2, so that's good news.
What's untrue about Arch? /usr/bin/python is python3 by default in there.
What Fedora is planning is leaving /usr/bin/python pointing to Py2, but making all their tools explicitly depend on and request Py3. This is distinctly different from the Arch decision, which instead resulted in fixing everything that expects `python` to mean Py2 to explicitly request Py2, or assisting with the porting process to Py3 for those applications.
Right -- on the other two (Gentoo and now Fedora) it's still Python 2 and Python 3 is /usr/bin/python3.
The one downside to this in terms of this move increasing adoptions is that RHEL 7 will be based on Fedora 19 not Fedora 20 and subsequent releases. If Python 3 managed to be default on RHEL/CentOS and the like, that would have a much broader impact.
Gentoo lets you choose the python dialect/version with "eselect python".
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.
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.
Well, "modify" could mean to just add !#/usr/bin/python2 to the top, right?
Right, but none of those changes can be merged upstream, because there are too many systems where "python2" does not exist (but some python2.x does). It was a royal PITA for anybody with build scripts written in Python: do you break your scripts for Arch, or do you break them for everybody else?
OTOH, it seems to have made Arch packagers above-average aware of the problem space. I ship a reasonably popular Linux desktop application that bundles a Python scripting interface and a set of scripts using it (altogether a minor feature of the application), and when we ported that code to Python 3 in a way that keeps it running on 2.7+ back in 2011, the Arch packager dutifully dropped their patch, making Arch the only distro to run it against Python 3. I'm not used to packagers who actually read release changelogs and/or dutifully drop redundant downstream customizations without explicit reminders, so that impressed me positively :).
A lot of the comments here seem to me to be based on a confusion between Python as a development tool for users and developers, and Python as a base operating system component. These are two very different roles that the language fills.
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.
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.
I try to never use any distro installed Python or libraries when developing Python software. In fact, I even went to the trouble of creating a self-contained Python build that had no dependencies whatsoever on distro-installed libraries. That way I have even more control over the foundation of my applications than you get with virtualenv.
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.
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.
Ok, so I'll state the obvious - it took almost 6 years from release of python 3.0.0 (2008-12-03)[1] till fedora adopting it. And I thought that cheap PHP hosts takes long time to upgrade PHP version.
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/
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/
You can see some reasons from one of the core developers here [0]:
"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-...
"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-...
Thanks for sharing this information. I am interested what strategies can be applied to increase the speed of language adoption.
> what strategies can be applied to increase the speed of language adoption.
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/
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/
There are large working Python 2 code bases in a lot of organizations. It works great. Fabulously reliable. Extremely well-tested. Been running great for years. They have no desire or need to upgrade and will run Python 2 and pay devs to maintain it forever.
Welcome to the real world.
Welcome to the real world.
You are right, just as there are still COBOL applications around.
It's not that it's not there -- Python 3 has been available on Fedora for years. It's that the system tools which use Python still use Python 2, which is itself still a modern, supported environment. TBH, I think it's probably correct for critical system scripts to be more conservative in upgrading.
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.
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.
One of the main differences with different PHP versions is that python 3 is not backwards compatible. Also, even after all these years, there are still quite some python projects that don't support python 3 (examples: mysqldb/twisted).
Just switching the interpreter from 2 to 3 is surely something that will give a lot of headaches.
No, PHP minor versions are not necessarily compatible with each other. When I worked in web hosting, we had to deal with quite a few issues resulting from changes between 5.2 and 5.3, and later 5.3 and 5.4.
At least Python has a sane versioning scheme, where breaking compatibility increments the major version number or is a bug.
At least Python has a sane versioning scheme, where breaking compatibility increments the major version number or is a bug.
I think the OP's point was that python 3 was never intended to be backwards compatible and intentionally broke compatibility in several places. For this reason, 2.7 continued to be supported for quite some time. I don't know a lot about PHP, but I'm guessing this was not the case for their minor version updates.
PHP changes were mostly, but not completely backwards compatible. There were a few corner cases were you'd get problems, but the majority of code would run fine on both systems.
I think you may just be confused about the specifics of "adopting it".
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.
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.
The switch isn't making python3 available; both python2 and python3 have been available for users for a long time. The switch means having the system tools rely on python3 rather than on python2, such that you can successfully install, boot, and configure a Fedora install without python2. This involved porting all the system code that uses python.
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.
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.
Twisted is one of the more important projects without Python3 support. This is their overview: http://twistedmatrix.com/trac/wiki/Plan/Python3
Twisted is 99% ported and already packaged in Ubuntu: http://packages.ubuntu.com/raring/python3-twisted-experiment...
The article provides a link to the TODO list: https://fedoraproject.org/wiki/User:Churchyard/python3
gentoo?
python 3.2.5 there (and not so later) by default and you can run oldest versions in parallel also
python 3.2.5 there (and not so later) by default and you can run oldest versions in parallel also
ok, but what took so long for fedora? (in other comment I read about ubuntu waiting just almost 5 years) why?
because is not actual and not main stream (it is about latest versions of python in distros)?
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.
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.
Python 3 was adopted in Fedora 13. 3.0 was not meant for production use (eg io library was pure python).
Fedora 22 is ... 3 releases out? So we're talking about 12-18 months depending on how soon F20 is due to be released. Still, I'm surprised, and I've been a Fedora contributor since FC5.
The interesting thing is of course:
>DNF is the default package manager instead of Yum, which only works with Python 2
Otherwise no big news, since all other major distros are switching to default python 3 too.
Otherwise no big news, since all other major distros are switching to default python 3 too.
DNF is a fork of Yum, so not that big news either.
This whole thing is no _big_ news at at all. I wonder what they define with "scope". If they are talking about 21+22 thats around ~12 months ahead, so even less big news.
A good way to get folks to make the switch.
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?
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?
Codechef appears to use Python 3.1.2 for "Python3", which is pretty old (March 21st, 2010) and predates some significant performance improvements in Python3[0].
[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...
[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...
I think readlines() is slower in python 3 due to unicode decoding. Python 2 did no decoding, readlines() returns python 2's str type, just bytes. You'd have to decode yourself (or decode the whole file in open()). Python 3 readlines() does decoding into unicode code points by default.
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.
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.
I think it is a little bit silly for a distro that claims to be bleeding edge... (freedom. friends. features. FIRST.)
Fedora is very much bleeding edge as far as stable distributions with set release cycles goes. First in the category of Ubuntu/Debian/openSUSE, not in the category of Arch/Gentoo.
This is not news. All distros will. News would be: Fedora, that normally is late, has switched to Python 3 a year after others.
"DNF is the default package manager instead of Yum, which only works with Python 2"
This will be interesting.
This will be interesting.
This will make some people to switch to other distributions, because in some cases making your software compatible with Python 3 is harder than changing distributions.
I don't think so because it is really easy to install Python 2 and have both versions installed.
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).
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).
That will still be the case. As the proposal makes clear, this will make the system tools use Python3, but "python" (/usr/bin/python) will still point to python2.7
That may be so, but this is the sort of mentality that was responsible for IE6 being maintained after the release of IE8.
In the long run, switching to python3 will be better.
In the long run, switching to python3 will be better.
Why isn't installing Python 2 an option?
The system might use python for other task, making python 2. as default may bring issues. I remember that installing python 3 on a version of ubuntu an making a symbolic link /usr/bin/python to python3 wrecked apt and the updating system.
> making python 2. as default may bring issues.
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?
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?
You can install both at the same time. "Default" here refers to what is installed by by default, and what the distro internal scripts are written in.
/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.
/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.
The PEP actually says "recommended" and "for the time being" -- there's no mandate that it be done one way or another:
"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)."
"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)."
And this is why I cringe every time someone puts:
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.
#!/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.
On Arch, the only issue I run into is typing python2/pip2 vs python/pip. The transition was smooth and nothing broke for me.
Let those people go
I understand the ressons for moving to Python 3. But I'm glad that most of my Python code runs on Windows.
I'm still using python 2.7 because many of my libraries require it, such as wxwidgets and pygame.
PyGame actually does mostly support Python 3. Their binaries seem to be a little old, though.
[deleted]
I wonder if this has any effect on the plans for CentOS? Somehow I suspect there would be more wailing and gnashing of teeth from that user community. (Not a criticism, just an appraisal of what CentOS folks do and how they're set up.)
CentOS still has python2.6 as the default. Several people I know who use CentOS with python just build their own python2.7 anyway -- at $dayjob, I build python2.7 and package it up with fpm[1] and drop it in our internal repo.
[1]: https://github.com/jordansissel/fpm
[1]: https://github.com/jordansissel/fpm
Great link to fpm! I'm definitely going to check that out.
Gushing a bit here, but it makes packaging things up soooo much nicer. It doesn't cover every use case of packaging, but it hits the sweet spot for quite a few things.
CentOS is just a rebranding of RHEL, which uses Fedora as upstream source. Basically when they start a new version of RHEL, they pick some Fedora version as a starting point, freeze things and make everything enterprise ready.
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.
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.
Wow. I was asking honestly, as a user of CentOS.
centos users had to live with python 2.4 until recently...
Is there a good reason that the Python project didn't just adopt a new command name and file extension for Python 3? It seems like that would have made the migration a lot less painful.
Great news!
it so bravery
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.