python program command executes Python 2. Python 3 can be executed using the
python3 command. How can Python 3 be executed using the
You can install a system-wide package:
$ sudo apt install python-is-python3
A simple safe way would be to use an alias. Place this into
After adding the above in the file, run
source ~/.bashrc or
$ python --version
$ python3 --version
$ alias python=python3
$ python --version
To circumvent the alias use the
command built-in command:
$ command python --version
Another way to circumvent the alias is to use
\ before the command.
$ \python --version
To disable the alias in the current shell use the
unalias built-in command:
$ unalias python
$ python --version
[June 2016] The recommended place for information on the transition is official Ubuntu Python page.
From the Ubuntu wiki:
What this does not mean:
/usr/bin/pythonwill point to Python 3. No, this is not going to happen (unless PEP 394 advocates otherwise, which is doubtful for the foreseeable future).
/usr/bin/python2will point to Python 2.7 and
/usr/bin/python3will point to the latest supported Python 3 version.
Python 2 will be removed from the archive. No, this is not going to happen. We expect Python 2.7 to remain supported and available in Ubuntu for quite a long time, given that PEP 373 promises upstream bug fix maintenance support until 2020.
It is not recommended to change the symbolic link because of other package dependencies, but they "have ongoing project goals to make Python 3 the default, preferred Python version in the distros".
For CLI use, like @Radu Rădeanu, I would recommend putting an alias in the user's
.bash_aliases file (the different files, including
~/.bash_profile, are loaded at least once, are mostly for organizational purposes, but may vary by platform). Python virtual environments also work well.
Scripts should still use something like
#!/usr/bin/env python3 for cross-compatibility.
env is nice for mixed use with virtual environments.
Note (thanks to @wjandrea): aliases are part of the bash runtime, not the user environment. Therefore, they are not available to the shebang (
#!). If you prefer the alias python=python3, then some
program.py without a shebang could be executed by invoking the aliased interpreter like this
python program.py. Aliasing may also be useful for systems with multiple version of python3 like 3.4 and 3.6 together.
Update: This is the wrong way, I have learned, since Python2 and Python3 are not interchangeable.
You can try the command line tool
$ sudo update-alternatives --config python
If you get the error "no alternatives for python" then set up an alternative yourself with the following command:
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 10
Change the path
/usr/bin/python3 to your desired python version accordingly.
Ubuntu, and the rest of the Linux distros for that matter, are still largely dependent on Python 2.7 for a number of applications and commands. If you change the default reference of "python" to Python 3.x, then a number of Python functions will start throwing assertion errors.
For example, on Ubuntu, 'pip' for one would no longer run correctly unless you directly edited the file and changed the shebang to reference '#!/usr/bin/env python2.7'. On RHEL (Red Hat Enterprise Linux) flavors such as Red Hat, Fedora and CentOS, the 'Yum' command is also dependent on Python 2.7.
My point here is that you would cause a significant amount of code to start throwing assertion errors just so you could type 'python' in the terminal to reference Python 3.x.
You're much better off with using the 'python3' command in the terminal and the shebang '#!/usr/bin/env python3' in your Python 3.x files.
then write either
Save the file, close the terminal and open it again.
I find it very helpful to simply remove /usr/bin/python and /usr/bin/pip. This forces all programs to rely on the "python2" and "python3" commands.
Although some optional and outdated packages depend on
#!/usr/bin/python to work, I would rather submit patches to those programs than continue to make weird and sometimes hard-to-debug mistakes.