Difference between revisions of "Python"

From ArchWiki
Jump to navigation Jump to search
m (Installation: package python3 does not exist)
m (Python 3: pip and virtualenv are separate package)
Line 28: Line 28:
{{Merge|Python VirtualEnv}}
{{Merge|Python VirtualEnv}}
Starting a new project inside a virtualenv is as simple as running:
Since Python 3.4.0, with the inclusion of [http://legacy.python.org/dev/peps/pep-0453/ PEP 453], {{ic|pip}} and {{ic|virtualenv}} are included by default with the Python binaries. Starting a new project inside a virtualenv is as simple as running:
  $ python -m venv newproj
  $ python -m venv newproj

Revision as of 14:14, 5 November 2014


From Wikipedia:

Python is a widely used general-purpose, high-level programming language. Its design philosophy emphasizes code readability, and its syntax allows programmers to express concepts in fewer lines of code than would be possible in languages such as C. The language provides constructs intended to enable clear programs on both a small and large scale.
Python supports multiple programming paradigms, including object-oriented, imperative and functional programming or procedural styles. It features a dynamic type system and automatic memory management, and has a large and comprehensive standard library.


Install the python and/or python2 packages available in the official repositories.

Python 3

Python 3 is the latest version of the language, and is incompatible with Python 2. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places. For an overview of the differences, visit Python2orPython3 and their relevant chapter in Dive into Python 3.

To install the latest version of Python 3, install the python package from the official repositories.

If you would like to build the latest RC/betas from source, visit Python Downloads. The Arch User Repository also contains good PKGBUILDs. If you do decide to build the RC, note that the binary (by default) installs to /usr/local/bin/python3.x.

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: The python package does not provide pip nor virtualenv commands, however, it does provide pyvenv command. (Discuss in Talk:Python#)

Merge-arrows-2.pngThis article or section is a candidate for merging with Python VirtualEnv.Merge-arrows-2.png

Notes: please use the second argument of the template to provide more detailed indications. (Discuss in Talk:Python#)

Starting a new project inside a virtualenv is as simple as running:

$ python -m venv newproj
$ source newproj/bin/activate
(newproj)$ pip install <dependency>

Python 2

To install the latest version of Python 2, install the python2 package from the official repositories.

Python 2 will happily run alongside Python 3. You need to specify python2 in order to run this version.

Any program requiring Python 2 needs to point to /usr/bin/python2, instead of /usr/bin/python, which points to Python 3.

To do so, open the program or script in a text editor and change the first line.

The line will show one of the following:

#!/usr/bin/env python



In both cases, just change python to python2 and the program will then use Python 2 instead of Python 3.

Another way to force the use of python2 without altering the scripts is to call it explicitely with python2, i.e.

python2 myScript.py

Finally, you may not be able to control the script calls, but there is a way to trick the environment. It only works if the scripts use #!/usr/bin/env python, it won't work with #!/usr/bin/python. This trick relies on env searching for the first corresponding entry in the PATH variable. First create a dummy folder.

$ mkdir ~/bin

Then add a symlink 'python' to python2 and the config scripts in it.

$ ln -s /usr/bin/python2 ~/bin/python
$ ln -s /usr/bin/python2-config ~/bin/python-config

Finally put the new folder at the beginning of your PATH variable.

$ export PATH=~/bin:$PATH

Note that this change is not permanent and is only active in the current terminal session. To check which python interpreter is being used by env, use the following command:

$ which python

Merge-arrows-2.pngThis article or section is a candidate for merging with Python VirtualEnv.Merge-arrows-2.png

Notes: please use the second argument of the template to provide more detailed indications. (Discuss in Talk:Python#)

A similar approach in tricking the environment, which also relies on #!/usr/bin/env python to be called by the script in question, is to use a Virtualenv. When a Virtualenv is activated, the Python executable pointed to by $PATH will be the one the Virtualenv was installed with. Therefore, if the Virtualenv is installed with Python 2, python will refer to Python 2. To start, install python2-virtualenv.

Then create the Virtualenv.

$ virtualenv2 venv # Creates a directory, venv/, containing the Virtualenv

Activate the Virtualenv, which will update $PATH to point at Python 2. Note that this activation is only active for the current terminal session.

$ source venv/bin/activate

The desired script should then run using Python 2.

Dealing with version problem in build scripts

Many projects' build scripts assume python to be Python 2, and that would eventually result in an error - typically complaining that print 'foo' is invalid syntax. Luckily, many of them call python in the $PATH instead of hardcoding #!/usr/bin/python in the shebang line, and the Python scripts are all contained within the project tree. So, instead of modifying the build scripts manually, there is an easy workaround. Just create /usr/local/bin/python with content like this:

script=$(readlink -f -- "$1")
case "$script" in (/path/to/project1/*|/path/to/project2/*|/path/to/project3*)
    exec python2 "$@"

exec python3 "$@"

Where /path/to/project1/*|/path/to/project2/*|/path/to/project3* is a list of patterns separated by | matching all project trees.

Don't forget to make it executable:

# chmod +x /usr/local/bin/python

Afterwards scripts within the specified project trees will be run with Python 2.

Getting completion in Python shell

Copy this into Python's interactive shell

import rlcompleter
import readline
readline.parse_and_bind("tab: complete")


Widget bindings

The following widget toolkit bindings are available:

  • TkInter — Tk bindings
http://wiki.python.org/moin/TkInter || standard module
  • pyQtQt bindings
http://www.riverbankcomputing.co.uk/software/pyqt/intro || python2-pyqt4 python2-pyqt5 python-pyqt4 python-pyqt5
  • pySideQt bindings
http://www.pyside.org/ || python2-pysideAUR python-pysideAUR
http://www.pygtk.org/ || pygtk
  • PyGObjectGTK+ 2/3 bindings via GObject Introspection
https://wiki.gnome.org/PyGObject/ || python2-gobject2 python2-gobject python-gobject2 python-gobject
  • wxPython — wxWidgets bindings
http://wxpython.org/ || wxpython

To use these with Python, you may need to install the associated widget kits.

Old versions

Old versions of Python are available via the AUR and may be useful for historical curiosity, old applications that don't run on current versions, or for testing Python programs intended to run on a distribution that comes with an older version (eg, RHEL 5.x has Python 2.4, or Ubuntu 12.04 has Python 3.1):

As of July 2014, Python upstream only supports Python 2.7, 3.2, 3.3, and 3.4 for security fixes. Using older versions for Internet-facing applications or untrusted code may be dangerous and is not recommended.

Extra modules/libraries for old versions of Python may be found on the AUR by searching for python(version without decimal), eg searching for "python26" for 2.6 modules.

Tips and tricks

IPython is a enhanced Python command line available in the official repositories as ipython and ipython2.

See also