8 ms·

Python is now Python 3

122 points by enduser 16y ago

JeremyBanks 16y ago
I failed to find a reference, but I seem to remember the Python team deciding at some point that they intended to keep the name "python" for the Python 2.X binaries perpetually, and require Python 3.X to be invoked as "python3". Arch might be alone in making this change, and inconsistent with other Python distributions. EDIT: I can't find a conclusive decision but here is one discussion on the subject: http://mail.python.org/pipermail/python-3000/2008-February/011910.html http://mail.python.org/pipermail/python-3000/2008-February/0...
- joelmichael 16y ago
  Arch has done this before. They only provide Ruby 1.9, even though 1.8 was (and remains today) the norm. I tried pointing this out and they told me to use a community package, which is unreliable and a huge pain. Their package philosophy is bleeding edge to an absurd degree, as it simply doesn't work. I stopped experimenting with Arch because of it.
  - vog 16y ago
    On the other hand, making your software work with Ruby 1.9 is something you'll have to do anyway, sooner or later. As long as there are no release-critical bugs in Ruby-1.9 ... which I guess aren't, because otherwise I don't think Arch would provide them.
  - Avshalom 16y ago
    Python3 is almost 2 years old this decision isn't about the bleeding edge, it's about damn time.
    - japherwocky 16y ago
      yeah.. in Python world it's still pretty bleeding edge. There's a reason they kept going with 2.7 in parallel with 3
      - xxpor 16y ago
        Would you consider Linux 2.6 'bleeding edge'? I mean, they have kept the 2.4 series going. Just because some development occurs in parallel, doesn't mean the new version is 'bleeding edge'.
        ubernostrum 16y ago
        The Python 3 migration process, for actual Python software in the wild, is and has always been meant to be a multi-year thing. As such, Python 3 is still very much "bleeding edge" in the sense that most projects are still working on their migration, and likely will be for some time.
        sigzero 16y ago
        I don't understand why more people don't get that. Guido has always said it will take a few years for it to all get over to P3. The Django folks are just now deciding when to get Django over to P3. If I have been watching the release notes for P3 versions as they come out and it still seems they are "cleaning up".
        japherwocky 16y ago
        You're correct, but you misunderstood me: I'm not saying it's bleeding edge because they're developing in parallel, I'm saying they're developing in parallel because it's bleeding edge. It's bleeding edge because the developers explicitly refer to it as "the shiny new thing", etc.
  - steveklabnik 16y ago
    This is one of those special case situations, since 1.9 has been the stable branch of Ruby since January of '09. That said, you're right, a sizable number of projects have stuck with 1.8.x, but you also can't blame the guys from Arch, either. 1.9.2 should change this.
  - poet 16y ago
    Ruby 1.8 is god awful and should be taken out back and shot. Several times. In no way should anything be done to support 1.8 as "the norm", especially after 1.9.2. Also, it's not like anyone should be using the system Ruby anyway. That's really bad practice in my opinion and there's no excuse when rvm exists.
    - mhansen 16y ago
      I don't use RVM, and I've got a few excuses: RVM doesn't work with fish. Fish is the biggest innovation in command-line shells in so long, and I'd rather drop RVM than drop fish. Also, RVM hijacked my 'cd' command, so that 'cd' wouldn't take me back to my home directory any more. I don't like things messing with workhorse commands that I depend on - 'cd' has to work.
      - poet 16y ago
        'cd' hijacking is definitely a bug. I can't reproduce that behavior. How long ago did that happen? Overall I've found rvm to be very solid software.
        mhansen 16y ago
        Not a bug - it's part of RVM's design. RVM reads .rvmrc files in each directory you change into. How does it do this? By redefining 'cd' to be a function wrapping the real CD command, with some extra RVM stuff in between the changing of directory and return. Check it out: http://github.com/wayneeseguin/rvm/blob/master/scripts/cd http://github.com/wayneeseguin/rvm/blob/master/scripts/cd My problems ('cd' with no arguments didn't take me back to my home directory any more) occurred about a month ago (I was using the fish interop mode - that might have been the problem), and it's probably been fixed since. But the whole thing scared me out of continuing with RVM. If there's a bug in RVM, I sure as hell don't want it to manifest in my 'cd' command. I need to be able to change directory, and my scripts rely on it to always work.
    - andrewvc 16y ago
      True, but those of us who have jobs working with ruby work with 1.8.7. We can't all rewrite our code from scratch you know.
  - axomhacker 16y ago
    Tangential, however I have found rvm to be incredible helpful in such situations. The ability to run multiple versions of Ruby with various sets of gems makes developing Ruby 1.8/1.9 apps painless. So much so that this is my default mechanism of running ruby anywhere (dev/prod). http://rvm.beginrescueend.com http://rvm.beginrescueend.com
  - bobbywilson0 16y ago
    "bleeding edge" doesn't usually refer to released software.
  - koenigdavidmj 16y ago
    Even Slackware only provides 1.9.x now. Use RVM if you still need 1.8.x for something.
  - javert 16y ago
    I haven't found that their package philosophy "simply doesn't work." It's worked pretty great for me. Maybe we're doing different things, though.
lvh 16y ago
As a result, #python has been full of people complaining their Python installs are hosed. Just like ruby1.8 -> ruby1.9, this was a bad move, and we told them (Gentoo as well) before they did it. I can only fully support my friend and very experienced Python hacker Allen when he says: 20:20 <dash> well that confirms my impression that arch was invented by a bunch of guys who thought gentoo was too stable and easy to use (Inflammatory, tongue in cheek, but oh-so HHOS.)
- deleted 16y ago
  [deleted]
- agentultra 16y ago
  Funny... I find it exceedingly easy to use. :) I've been using it for over two years now. Makes a great workstation OS. You get the latest releases and all their attended bug fixes, security updates, and yes.. new bugs. But at least in the Python world, there's still virtualenv, buildout, pip, etc. I rarely install system packages for libs anyway. I don't really see how this is going to bring down the house. At the least if it does work out well and makes enough people happy, there will be more reason for people to hurry up the transition to py3 already. (An aside: as much as I disagree with py3 forgoing practicality for purity, I wish the transition would be over already so we can get on gettin on).
  - aw3c2 16y ago
    I noticed the news post a day before my latest update, so I was prepared too. One should always follow package source's and general news of the distribution one uses.
- psadauskas 16y ago
  Arch has the least amount of breakage of any distro I've ever used. Slack, Redhat, Gentoo, all of them would occasionally shit all over themselves, and it would sometimes be tricky to fix. The couple times that Arch did that, it was really easy to fix, because things were "normal". The Arch philosophy seems to be to defer to upstream as much as possible, which makes things easy to fix.
- 16y ago
sprout 16y ago
Call me when a distro that implements package signing has shipped Python 3. I know it's a little OT, but I can't take anyone seriously who ships unsigned packages and calls them a distribution.
- mapleoin 16y ago
  http://fedoraproject.org/wiki/Features/Python3F13 http://fedoraproject.org/wiki/Features/Python3F13 (Fedora 13 was released on the 25th of May).
- jmillikin 16y ago
  Ubuntu uses signed packages, and has been shipping Python 3 for some time. Debian probably includes it in their unstable repository.
- hackerr 16y ago
  Based on the tenor of your comments and OT nature of it, I also cannot take anyone seriously who talks like this, without appropriate context.
- eru 16y ago
  Do you know why Arch does not sign its packages?
deleted 16y ago
[deleted]
Kadin 16y ago
Not a good move. Considering the large base of programs that expect Python 2.x, the safe thing to do would be to keep /usr/bin/python pointing at the 2.x binaries while using /usr/bin/python3 for the 3.x ones. At some point in the future if Python 2.x really is dead, you can just point both python and python3 at the same thing. This seems more like somebody trying to evangelize for Python 3 and against Python 2, by purposely breaking a lot of old software, and quite antithetical to the Robustness Principle that I would expect most good software to at least attempt to shoot for. Hopefully other distros will take a more conservative path. Python 2.x is going to be around for a long, long time.
- Eil 16y ago
  Chances are exceedingly good that Arch package maintainers will be checking their Python applications and updating them to use /usr/bin/python2 if they don't run under Python 3. Actually, this should have already happened since the change has apparently been in testing for awhile.
  - patd 16y ago
    I'm not really familiar with what Arch package maintainers do but aren't package maintainer mainly packager and not coders ? I imagine that someone could easily be packaging 10 Python apps or libraries. He can't be upgrading all that code to Python 3 as it is not always a trivial task and would require a lot of work and constant patching if the developing team keeps working with Python 2.X But overall, I think this is a good way to push developers to upgrade or at least prepare more to move to Python 3.
    - nixme 16y ago
      You're misunderstanding. Arch is still shipping Python 2.7 with the python2 package. So package maintainers don't need to rewrite upstream code if it's not compatible with Python 3; they just need to update dependencies and set paths to point to the /usr/bin/python2 binary.
- drawkbox 16y ago
jedbrown 16y ago
I'm using Arch and the transition was smooth for all the packaged libraries including Numpy, Scipy, matplotlib, and friends, as well as pure Python packages like mpi4py and petsc4py which I install from upstream since I track development versions. The real pain is for projects that are not pure python libraries, but want to ship portable scripts. Since the "python2" link is not ubiquitous, they cannot put "/usr/bin/env python2" in the scripts (like Arch packages do, perhaps just using sed). Unfortunately there are still modern installs of Python that do not have "python2" links, so this is going to be a long process when it's not feasible to support both python-2.x and python-3 within an identical codebase. That is challenging if you have to support e.g. python2.3 which will be around for a while longer (RHEL4). Also, RHEL5 (rather, the CentOS system I have a login on) does not have a python2 link (it has python2.4) and that will be around for another four years. I think Arch's decision was a bit premature, but waiting isn't going to make the issues much less painful if your project will always have to support an 8-year age span of distributions.
- naner 16y ago
  I think Arch's decision was a bit premature This change has only been made in the 'testing' repositories.
  - mziulu 16y ago
    Not really, Arch's default python right now is python3.
  - crocowhile 16y ago
    Nope. Python3 is now default python in the regular repos. It was in the testing for a while and has been approved. Didn't like the move myself. pygtk broke for me and with it a small bunch of other softwares.
kenneth_reitz 16y ago
This was very foolish.
enduser 16y ago
This has been in testing for some time in Arch. The Python maintainers decided to hold off on releasing 2.7 until all packages depending on Python could be rebuilt to make the switch from UCS-2 to UCS-4. Now Python 3 and Python 2 are both UCS-4, and the 'python2' package is 2.7. I updated Arch on my workstation and server today and can confirm that everything "works for me" except for some python packages installed manually from AUR (e.g. offlineimap). Make sure to check your AUR packages.
bsergean 16y ago
It's a bold move that gonna make python move forward. Congratulation Arch Linux.
steiger 16y ago
As I see it, the change is minor and doesn't have any practical consequences, except for: (1) the extra work for Arch packagers, who will need to change, in all packages, every Python2.x code that expects /usr/bin/python to be a Python2.x interpreter. (2) making Python 3.x feel like the de facto standard in the distribution sphere.
kprobst 16y ago
Too many third party libs and packages still don't support PY3. Not a good idea.
ginkgo 16y ago
This update broke the python-cheetah package which I was relying on. For now, I have to use a self-compiled 2.6 python package. I have locked the python and python2 packages from further updates for now. I hope this situation get better soon.
- klodolph 16y ago
  I hope you submitted a bug against python-cheetah...? (This kind of thing is what I signed up for when I installed Arch.)
sunqiang 16y ago
I think the real point is how many third party libs and packages support Python 3 yet. http://dev.pocoo.org/~gbrandl/py3.html http://dev.pocoo.org/~gbrandl/py3.html
- enduser 16y ago
  Most Python programmers only use a handful of significant third party libs. I use fewer than a dozen. What is more significant is WSGI, which still has not been finalized for Python 3. There are two competing, unimplemented PEPS: 444 and 3333. I have also heard some comments about the Python 3 standard library leaving some things to be desired. Perhaps someone more knowledgeable can elaborate.
  - sunqiang 16y ago
    for web (framework). Google App Engine still depends on Python 2, Django has some hesitates for the Python 3 port[1], the thread has some discuss about Python 3.2, peps 333(3) too. and have a Python 3 version itself is not the same thing it can be put into production as it's tried-and-true Python 2 version. [1] http://www.gossamer-threads.com/lists/python/dev/862066#862066 http://www.gossamer-threads.com/lists/python/dev/862066#8620...
Mithrandir 16y ago
Interesting discussions on it at: http://tinyurl.com/2cepr72 http://tinyurl.com/2cepr72 and http://tinyurl.com/25pgqql http://tinyurl.com/25pgqql More in-depth post at: http://allanmcrae.com/2010/10/big-python-transition-in-arch-linux/ http://allanmcrae.com/2010/10/big-python-transition-in-arch-... Seems there's not a lot of uproar or cheering on it (though it depends on who's doing the posting.)
cagenut 16y ago
I'm grateful for arch and its users, like gentoo users before them, for being a giant expendable human wave of beta-testing to make my life with foss easier.
- beej71 16y ago
  I absolutely agree, as an Arch user, with everything you say, except for the "expendable" part. Seriously, some distro had to be first, and which one is better positioned than Arch both technically and philosophically to take that hit? All the other distros can watch and learn. (And I can finally learn all the stuff I have to do to make my scripts work with python3.)
  - RexRollman 16y ago
    I agree. I use Arch and I think it is the best Linux distro I have ever installed.
- beej71 16y ago
  Or, to quote Allan McRae: "Arch is bleeding edge. We do things first. We experience the pain before others. That what makes us full of awesome."
metamemetics 16y ago
Use Buildout and get a python shell for any version you want in your project directory. Then add a few things to your .gitignore and distribute/deploy.
code_duck 16y ago
Good. Someone had to step up and do this eventually.
- mfukar 16y ago
  Indeed. Python is moving forward, and 3.1.2 should be the default. For backwards compatibility, install 2.4.ancient1. I'm not using Arch, but choices like this really improve its standing in my eyes.
prog 16y ago
I recently started a new project but had to go for 2.7 instead of 3.x due to the lack of 3.x support in Django. I would have loved to use 3.x. Oh well.
zokier 16y ago
Reminds me of Zeds rant 'Making Debian Responsible For Its Actions'. http://news.ycombinator.com/item?id=1734936 http://news.ycombinator.com/item?id=1734936
pmarin 16y ago
Why not simply start using /usr/bin/python3 always for Python 3?

122 points by enduser 16y ago

I failed to find a reference, but I seem to remember the Python team deciding at some point that they intended to keep the name "python" for the Python 2.X binaries perpetually, and require Python 3.X to be invoked as "python3". Arch might be alone in making this change, and inconsistent with other Python distributions. EDIT: I can't find a conclusive decision but here is one discussion on the subject: http://mail.python.org/pipermail/python-3000/2008-February/011910.html http://mail.python.org/pipermail/python-3000/2008-February/0...

joelmichael 16y ago
Arch has done this before. They only provide Ruby 1.9, even though 1.8 was (and remains today) the norm. I tried pointing this out and they told me to use a community package, which is unreliable and a huge pain. Their package philosophy is bleeding edge to an absurd degree, as it simply doesn't work. I stopped experimenting with Arch because of it.
- vog 16y ago
  On the other hand, making your software work with Ruby 1.9 is something you'll have to do anyway, sooner or later. As long as there are no release-critical bugs in Ruby-1.9 ... which I guess aren't, because otherwise I don't think Arch would provide them.
- Avshalom 16y ago
  Python3 is almost 2 years old this decision isn't about the bleeding edge, it's about damn time.
  - japherwocky 16y ago
    yeah.. in Python world it's still pretty bleeding edge. There's a reason they kept going with 2.7 in parallel with 3
    - xxpor 16y ago
      Would you consider Linux 2.6 'bleeding edge'? I mean, they have kept the 2.4 series going. Just because some development occurs in parallel, doesn't mean the new version is 'bleeding edge'.
      - ubernostrum 16y ago
        The Python 3 migration process, for actual Python software in the wild, is and has always been meant to be a multi-year thing. As such, Python 3 is still very much "bleeding edge" in the sense that most projects are still working on their migration, and likely will be for some time.
        sigzero 16y ago
        I don't understand why more people don't get that. Guido has always said it will take a few years for it to all get over to P3. The Django folks are just now deciding when to get Django over to P3. If I have been watching the release notes for P3 versions as they come out and it still seems they are "cleaning up".
      - japherwocky 16y ago
        You're correct, but you misunderstood me: I'm not saying it's bleeding edge because they're developing in parallel, I'm saying they're developing in parallel because it's bleeding edge. It's bleeding edge because the developers explicitly refer to it as "the shiny new thing", etc.
- steveklabnik 16y ago
  This is one of those special case situations, since 1.9 has been the stable branch of Ruby since January of '09. That said, you're right, a sizable number of projects have stuck with 1.8.x, but you also can't blame the guys from Arch, either. 1.9.2 should change this.
- poet 16y ago
  Ruby 1.8 is god awful and should be taken out back and shot. Several times. In no way should anything be done to support 1.8 as "the norm", especially after 1.9.2. Also, it's not like anyone should be using the system Ruby anyway. That's really bad practice in my opinion and there's no excuse when rvm exists.
  - mhansen 16y ago
    I don't use RVM, and I've got a few excuses: RVM doesn't work with fish. Fish is the biggest innovation in command-line shells in so long, and I'd rather drop RVM than drop fish. Also, RVM hijacked my 'cd' command, so that 'cd' wouldn't take me back to my home directory any more. I don't like things messing with workhorse commands that I depend on - 'cd' has to work.
    - poet 16y ago
      'cd' hijacking is definitely a bug. I can't reproduce that behavior. How long ago did that happen? Overall I've found rvm to be very solid software.
      - mhansen 16y ago
        Not a bug - it's part of RVM's design. RVM reads .rvmrc files in each directory you change into. How does it do this? By redefining 'cd' to be a function wrapping the real CD command, with some extra RVM stuff in between the changing of directory and return. Check it out: http://github.com/wayneeseguin/rvm/blob/master/scripts/cd http://github.com/wayneeseguin/rvm/blob/master/scripts/cd My problems ('cd' with no arguments didn't take me back to my home directory any more) occurred about a month ago (I was using the fish interop mode - that might have been the problem), and it's probably been fixed since. But the whole thing scared me out of continuing with RVM. If there's a bug in RVM, I sure as hell don't want it to manifest in my 'cd' command. I need to be able to change directory, and my scripts rely on it to always work.
  - andrewvc 16y ago
    True, but those of us who have jobs working with ruby work with 1.8.7. We can't all rewrite our code from scratch you know.
- axomhacker 16y ago
  Tangential, however I have found rvm to be incredible helpful in such situations. The ability to run multiple versions of Ruby with various sets of gems makes developing Ruby 1.8/1.9 apps painless. So much so that this is my default mechanism of running ruby anywhere (dev/prod). http://rvm.beginrescueend.com http://rvm.beginrescueend.com
- bobbywilson0 16y ago
  "bleeding edge" doesn't usually refer to released software.
- koenigdavidmj 16y ago
  Even Slackware only provides 1.9.x now. Use RVM if you still need 1.8.x for something.
- javert 16y ago
  I haven't found that their package philosophy "simply doesn't work." It's worked pretty great for me. Maybe we're doing different things, though.

lvh 16y ago

As a result, #python has been full of people complaining their Python installs are hosed. Just like ruby1.8 -> ruby1.9, this was a bad move, and we told them (Gentoo as well) before they did it. I can only fully support my friend and very experienced Python hacker Allen when he says: 20:20 <dash> well that confirms my impression that arch was invented by a bunch of guys who thought gentoo was too stable and easy to use (Inflammatory, tongue in cheek, but oh-so HHOS.)

deleted 16y ago
[deleted]
agentultra 16y ago
Funny... I find it exceedingly easy to use. :) I've been using it for over two years now. Makes a great workstation OS. You get the latest releases and all their attended bug fixes, security updates, and yes.. new bugs. But at least in the Python world, there's still virtualenv, buildout, pip, etc. I rarely install system packages for libs anyway. I don't really see how this is going to bring down the house. At the least if it does work out well and makes enough people happy, there will be more reason for people to hurry up the transition to py3 already. (An aside: as much as I disagree with py3 forgoing practicality for purity, I wish the transition would be over already so we can get on gettin on).
- aw3c2 16y ago
  I noticed the news post a day before my latest update, so I was prepared too. One should always follow package source's and general news of the distribution one uses.
psadauskas 16y ago
Arch has the least amount of breakage of any distro I've ever used. Slack, Redhat, Gentoo, all of them would occasionally shit all over themselves, and it would sometimes be tricky to fix. The couple times that Arch did that, it was really easy to fix, because things were "normal". The Arch philosophy seems to be to defer to upstream as much as possible, which makes things easy to fix.
16y ago

sprout 16y ago

Call me when a distro that implements package signing has shipped Python 3. I know it's a little OT, but I can't take anyone seriously who ships unsigned packages and calls them a distribution.

mapleoin 16y ago
http://fedoraproject.org/wiki/Features/Python3F13 http://fedoraproject.org/wiki/Features/Python3F13 (Fedora 13 was released on the 25th of May).
jmillikin 16y ago
Ubuntu uses signed packages, and has been shipping Python 3 for some time. Debian probably includes it in their unstable repository.
hackerr 16y ago
Based on the tenor of your comments and OT nature of it, I also cannot take anyone seriously who talks like this, without appropriate context.
eru 16y ago
Do you know why Arch does not sign its packages?

deleted 16y ago

[deleted]

Kadin 16y ago

Not a good move. Considering the large base of programs that expect Python 2.x, the safe thing to do would be to keep /usr/bin/python pointing at the 2.x binaries while using /usr/bin/python3 for the 3.x ones. At some point in the future if Python 2.x really is dead, you can just point both python and python3 at the same thing. This seems more like somebody trying to evangelize for Python 3 and against Python 2, by purposely breaking a lot of old software, and quite antithetical to the Robustness Principle that I would expect most good software to at least attempt to shoot for. Hopefully other distros will take a more conservative path. Python 2.x is going to be around for a long, long time.

Eil 16y ago
Chances are exceedingly good that Arch package maintainers will be checking their Python applications and updating them to use /usr/bin/python2 if they don't run under Python 3. Actually, this should have already happened since the change has apparently been in testing for awhile.
- patd 16y ago
  I'm not really familiar with what Arch package maintainers do but aren't package maintainer mainly packager and not coders ? I imagine that someone could easily be packaging 10 Python apps or libraries. He can't be upgrading all that code to Python 3 as it is not always a trivial task and would require a lot of work and constant patching if the developing team keeps working with Python 2.X But overall, I think this is a good way to push developers to upgrade or at least prepare more to move to Python 3.
  - nixme 16y ago
    You're misunderstanding. Arch is still shipping Python 2.7 with the python2 package. So package maintainers don't need to rewrite upstream code if it's not compatible with Python 3; they just need to update dependencies and set paths to point to the /usr/bin/python2 binary.
drawkbox 16y ago

jedbrown 16y ago

I'm using Arch and the transition was smooth for all the packaged libraries including Numpy, Scipy, matplotlib, and friends, as well as pure Python packages like mpi4py and petsc4py which I install from upstream since I track development versions. The real pain is for projects that are not pure python libraries, but want to ship portable scripts. Since the "python2" link is not ubiquitous, they cannot put "/usr/bin/env python2" in the scripts (like Arch packages do, perhaps just using sed). Unfortunately there are still modern installs of Python that do not have "python2" links, so this is going to be a long process when it's not feasible to support both python-2.x and python-3 within an identical codebase. That is challenging if you have to support e.g. python2.3 which will be around for a while longer (RHEL4). Also, RHEL5 (rather, the CentOS system I have a login on) does not have a python2 link (it has python2.4) and that will be around for another four years. I think Arch's decision was a bit premature, but waiting isn't going to make the issues much less painful if your project will always have to support an 8-year age span of distributions.

naner 16y ago
I think Arch's decision was a bit premature This change has only been made in the 'testing' repositories.
- mziulu 16y ago
  Not really, Arch's default python right now is python3.
- crocowhile 16y ago
  Nope. Python3 is now default python in the regular repos. It was in the testing for a while and has been approved. Didn't like the move myself. pygtk broke for me and with it a small bunch of other softwares.

kenneth_reitz 16y ago

This was very foolish.

enduser 16y ago

This has been in testing for some time in Arch. The Python maintainers decided to hold off on releasing 2.7 until all packages depending on Python could be rebuilt to make the switch from UCS-2 to UCS-4. Now Python 3 and Python 2 are both UCS-4, and the 'python2' package is 2.7. I updated Arch on my workstation and server today and can confirm that everything "works for me" except for some python packages installed manually from AUR (e.g. offlineimap). Make sure to check your AUR packages.

bsergean 16y ago

It's a bold move that gonna make python move forward. Congratulation Arch Linux.

steiger 16y ago

As I see it, the change is minor and doesn't have any practical consequences, except for: (1) the extra work for Arch packagers, who will need to change, in all packages, every Python2.x code that expects /usr/bin/python to be a Python2.x interpreter. (2) making Python 3.x feel like the de facto standard in the distribution sphere.

kprobst 16y ago

Too many third party libs and packages still don't support PY3. Not a good idea.

ginkgo 16y ago

This update broke the python-cheetah package which I was relying on. For now, I have to use a self-compiled 2.6 python package. I have locked the python and python2 packages from further updates for now. I hope this situation get better soon.

klodolph 16y ago
I hope you submitted a bug against python-cheetah...? (This kind of thing is what I signed up for when I installed Arch.)

sunqiang 16y ago

I think the real point is how many third party libs and packages support Python 3 yet. http://dev.pocoo.org/~gbrandl/py3.html http://dev.pocoo.org/~gbrandl/py3.html

enduser 16y ago
Most Python programmers only use a handful of significant third party libs. I use fewer than a dozen. What is more significant is WSGI, which still has not been finalized for Python 3. There are two competing, unimplemented PEPS: 444 and 3333. I have also heard some comments about the Python 3 standard library leaving some things to be desired. Perhaps someone more knowledgeable can elaborate.
- sunqiang 16y ago
  for web (framework). Google App Engine still depends on Python 2, Django has some hesitates for the Python 3 port[1], the thread has some discuss about Python 3.2, peps 333(3) too. and have a Python 3 version itself is not the same thing it can be put into production as it's tried-and-true Python 2 version. [1] http://www.gossamer-threads.com/lists/python/dev/862066#862066 http://www.gossamer-threads.com/lists/python/dev/862066#8620...

Mithrandir 16y ago

Interesting discussions on it at: http://tinyurl.com/2cepr72 http://tinyurl.com/2cepr72 and http://tinyurl.com/25pgqql http://tinyurl.com/25pgqql More in-depth post at: http://allanmcrae.com/2010/10/big-python-transition-in-arch-linux/ http://allanmcrae.com/2010/10/big-python-transition-in-arch-... Seems there's not a lot of uproar or cheering on it (though it depends on who's doing the posting.)

cagenut 16y ago

I'm grateful for arch and its users, like gentoo users before them, for being a giant expendable human wave of beta-testing to make my life with foss easier.

beej71 16y ago
I absolutely agree, as an Arch user, with everything you say, except for the "expendable" part. Seriously, some distro had to be first, and which one is better positioned than Arch both technically and philosophically to take that hit? All the other distros can watch and learn. (And I can finally learn all the stuff I have to do to make my scripts work with python3.)
- RexRollman 16y ago
  I agree. I use Arch and I think it is the best Linux distro I have ever installed.
beej71 16y ago
Or, to quote Allan McRae: "Arch is bleeding edge. We do things first. We experience the pain before others. That what makes us full of awesome."

metamemetics 16y ago

Use Buildout and get a python shell for any version you want in your project directory. Then add a few things to your .gitignore and distribute/deploy.

code_duck 16y ago

Good. Someone had to step up and do this eventually.

mfukar 16y ago
Indeed. Python is moving forward, and 3.1.2 should be the default. For backwards compatibility, install 2.4.ancient1. I'm not using Arch, but choices like this really improve its standing in my eyes.

prog 16y ago

I recently started a new project but had to go for 2.7 instead of 3.x due to the lack of 3.x support in Django. I would have loved to use 3.x. Oh well.

zokier 16y ago

Reminds me of Zeds rant 'Making Debian Responsible For Its Actions'. http://news.ycombinator.com/item?id=1734936 http://news.ycombinator.com/item?id=1734936

pmarin 16y ago

Why not simply start using /usr/bin/python3 always for Python 3?