

Python is now Python 3 - enduser
http://www.archlinux.org/news/python-is-now-python-3/

======
jedbrown
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
_I think Arch's decision was a bit premature_

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

~~~
crocowhile
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.

------
lvh
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
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
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.

------
Kadin
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
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.

~~~
chrisbolt
Did Apple really make a 'breaking change' with the switch to Intel? PPC apps
ran with a PPC emulator. As far as I know they didn't break, they were just
deprecated.

There's a big difference between breaking and deprecation.

~~~
eru
Python2 is also still around, if you need it.

~~~
wahnfrieden
It's not around as `python2` on other distros though, which is the problem.
Either all other distros have to change to conform to arch, or arch has to
change it back to how it was.

~~~
eru
My Ubuntu has python2.

------
JeremyBanks
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...](http://mail.python.org/pipermail/python-3000/2008-February/011910.html)

~~~
joelmichael
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.

~~~
poet
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
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
'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
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>

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.

------
cagenut
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
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
I agree. I use Arch and I think it is the best Linux distro I have ever
installed.

------
enduser
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
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
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
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#8620...](http://www.gossamer-
threads.com/lists/python/dev/862066#862066)

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

~~~
mfukar
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.

------
Mithrandir
Interesting discussions on it at: <http://tinyurl.com/2cepr72> and
<http://tinyurl.com/25pgqql>

More in-depth post at: [http://allanmcrae.com/2010/10/big-python-transition-
in-arch-...](http://allanmcrae.com/2010/10/big-python-transition-in-arch-
linux/)

Seems there's not a lot of uproar or cheering on it (though it depends on
who's doing the posting.)

------
steiger
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
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
I hope you submitted a bug against python-cheetah...?

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

------
prog
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
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
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
Ubuntu uses signed packages, and has been shipping Python 3 for some time.
Debian probably includes it in their unstable repository.

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

------
zokier
Reminds me of Zeds rant 'Making Debian Responsible For Its Actions'.

<http://news.ycombinator.com/item?id=1734936>

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

------
kenneth_reitz
This was very foolish.

