top | item 1808840

Python is now Python 3

122 points| enduser | 15 years ago |archlinux.org | reply

64 comments

order
[+] jedbrown|15 years ago|reply
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|15 years ago|reply
I think Arch's decision was a bit premature

This change has only been made in the 'testing' repositories.

[+] lvh|15 years ago|reply
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.)

[+] agentultra|15 years ago|reply
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).

[+] psadauskas|15 years ago|reply
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.
[+] hackerr|15 years ago|reply
You can't always decide something is good or bad based on number of people running to IRC asking for help. Well let me make another "tongue in cheek" -- many o f them should be told to RTFM and read their distro's announcements". Don't support lazy folks who fail to do that.
[+] Kadin|15 years ago|reply
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.

[+] drawkbox|15 years ago|reply
The platforms making bold enough breaking changes to progress are usually better for it. One case Apple on intel/OSX. Granted this is painful for legacy stuff but that only helps keep things up to date. If people don't start doing this Python 3 will never progress.

However, there should be no 'default' python. People should go get 2 or 3 as needed. If there is a default it should be the latest version.

[+] Eil|15 years ago|reply
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.
[+] JeremyBanks|15 years ago|reply
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/0...

[+] joelmichael|15 years ago|reply
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.
[+] cagenut|15 years ago|reply
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|15 years ago|reply
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."

[+] beej71|15 years ago|reply
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.)

[+] enduser|15 years ago|reply
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.

[+] sunqiang|15 years ago|reply
I think the real point is how many third party libs and packages support Python 3 yet. http://dev.pocoo.org/~gbrandl/py3.html
[+] enduser|15 years ago|reply
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.

[+] code_duck|15 years ago|reply
Good. Someone had to step up and do this eventually.
[+] mfukar|15 years ago|reply
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.

[+] steiger|15 years ago|reply
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.

[+] ginkgo|15 years ago|reply
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|15 years ago|reply
I hope you submitted a bug against python-cheetah...?

(This kind of thing is what I signed up for when I installed Arch.)

[+] prog|15 years ago|reply
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.
[+] metamemetics|15 years ago|reply
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.
[+] sprout|15 years ago|reply
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.

[+] jmillikin|15 years ago|reply
Ubuntu uses signed packages, and has been shipping Python 3 for some time. Debian probably includes it in their unstable repository.
[+] hackerr|15 years ago|reply
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|15 years ago|reply
Do you know why Arch does not sign its packages?
[+] pmarin|15 years ago|reply
Why not simply start using /usr/bin/python3 always for Python 3?
[+] kprobst|15 years ago|reply
Too many third party libs and packages still don't support PY3. Not a good idea.