[IPython-dev] [sympy] Treating Python 3 as a first-class citizen
Sun Aug 4 19:11:08 CDT 2013
On Sun, Aug 4, 2013 at 5:34 PM, Aaron Meurer <email@example.com> wrote:
> I'm sending this email to the lists of three projects that I am
> involved with that have this issue. Please reply-all to all the lists
> you are on. Feel free to add in any other lists that have the same
> As many of you may know, SymPy recently converted its codebase to a
> single code base for Python 2 and Python 3. This, along with some of
> the work I've done at Continuum with the conda package manager this
> summer, has gotten me thinking about how we treat Python 3 when we
> install our software.
> In particular, we tend to install entry points that have a 3 suffix.
> So for example, IPython installs ipython3. PuDB installs pudb3 (this
> one was entirely my contribution, but I didn't know any better at the
> time). SymPy is considering installing an isympy3.
> I think this is bad for anyone who wants to use Python 3, because if
> they install IPython (for example), they won't get "ipython", but
> rather "ipython3". This makes Python 3, and anything installed in it,
> a second class citizen, because the default "ipython" is always
> pointing to Python 2.
> Now, the reason that this was done is that the typical installation
> uses a shared bin directory (generally /usr/bin/), so if you wanted to
> install both Python 2 and Python 3 versions of the software, the entry
> point in bin would be whatever was installed most recently.
> If you use something like conda environments or virtualenvs, this
> issue doesn't present itself, because you can only have one Python
> installed in an environment at a time. In that situation, it is really
> annoying to install IPython and not have "ipython" (it can also be
> confusing, because if you prepend the environment to your PATH, typing
> "ipython" will still point to some other Python 2 IPython installed
> somewhere else). It's also annoying if you want to use only Python 3.
The standard way that Python is installed in Debian/Ubuntu is that
you have python3.2, python2.7, python2.6, python2.5, ..., and then you have
"python", which is just a symlink, on my system it is:
ondrej@hawk:~$ ll /usr/bin/python
lrwxrwxrwx 1 root root 9 Jun 18 11:26 /usr/bin/python -> python2.7*
As such, I think the "setup.py" install should simply install just one
ipython (or isympy, pudb),
which uses whatever Python it is installed into. I would treat Python
3.2 or 3.3 exactly like
2.7 or 2.5 ---- just another version of Python.
In particular, if we agree to treat Python 3.2 or 3.3 just like 2.5 or
2.6, then if you use python 2.6
to call "setup.py", then isympy should really be using this very same
Python 2.6, not any other 2.x.
The reason is, that for ipython you install all the dependencies into
Python 2.6, so you can't then
call other Python.
Distributions like Debian then simply install it couple times for each
Python, or create the proper
> So I'm wondering what people think we should do about this. I
> definitely think that it should be possible to install "ipython",
> "pudb", and "isympy" entry points that point to Python 3. But should
> that be the default?
Based on the above, if you use python 3.3 to run "setup.py", then
use Python 3.3. If you use Python 2.7, it should use Python 2.7. And
if you use Python 2.6,
you should use Python 2.6.
> Should we keep the 3 suffixed versions for
> backwards compatibility?
I wouldn't. Alternatively, we can create isympy2.6 and then isympy
would link to this (and the same
for other Python versions), but I would probably leave this for the
Debian (and other) distribution to handle.
More information about the IPython-dev