Sublime Text

Sublime Text is our recommended text editor for code, markup, and prose. Its speed is the first thing cited when people recommend it; the number of packages available (3,000+) is next.

Sublime Text was first released in 2008 by Jon Skinner. Written in Python, it has excellent support for editing Python code and uses Python for its package extension API. A “Projects” feature allows the user to add/remove files or folders—these can then be searched via the “Goto Anything” function, which identifies locations within the project that contain the search term(s).

You need PackageControl to access the Sublime Text package repository. Popular packages include SublimeLinter, an interface to the user’s selection of installed static code checkers; Emmett for web development snippets;² and Sublime SFTP for remote editing via FTP.

Anaconda (no relation to the commercial Python distribution of the same name), released in 2013, by itself turns Sublime almost into an IDE, complete with static code checks, docstring checks, a test runner, and capability to look up the definition of or locate uses of highlighted objects.

Vim

Vim is a console-based text editor (with optional GUI) that uses keyboard shortcuts for editing instead of menus or icons. It was first released in 1991 by Bram Moolenaar, and its predecessor, Vi, was released in 1976 by Bill Joy. Both are written in C.

Vim is extensible via vimscript, a simple scripting language. There are options to use other languages: to enable Python scripting, set the build configuration flags when building from the C source to --enable-pythoninterp and/or --enable-python3interp before you build from source. To check whether Python or Python3 are enabled, type :echo has("python") or :echo has("python3"); the result will be “1” if True or “0” if False.

Vi (and frequently Vim) is available out of the box on pretty much every system but Windows, and there is an executable installer for Vim on Windows. Users who can tolerate the learning curve will become extremely efficient; so much that the basic Vi key bindings are available as a configuration option in most other editors and IDEs.

If you only develop in Python, you can set the default settings for indentation and line wrapping to values compliant with PEP 8. To do that, create a file called .vimrc in your home directory,⁴ and add the following:

set textwidth=79  " lines longer than 79 columns will be broken
set shiftwidth=4  " operation >> indents 4 columns; << unindents 4 columns
set tabstop=4     " a hard TAB displays as 4 columns
set expandtab     " insert spaces when hitting TABs
set softtabstop=4 " insert/delete 4 spaces when hitting a TAB/BACKSPACE
set shiftround    " round indent to multiple of 'shiftwidth'
set autoindent    " align the new line indent with the previous line

With these settings, newlines are inserted after 79 characters and indentation is set to four spaces per tab, and if you are inside an indented statement, your next line will also be indented to the same level.

There is also a syntax plug-in called python.vim that features some improvements over the syntax file included in Vim 6.1, and a small plug-in, SuperTab, that makes code completion more convenient by using the Tab key or any other customized keys. If you also use Vim for other languages, there is a handy plug-in called indent, which handles indentation settings for Python source files.

These plug-ins supply you with a basic environment for developing in Python. If your Vim is compiled with +python (the default for Vim 7 and newer), you can also use the plug-in vim-flake8 to do static code checks from within the editor. It provides the function Flake8, which runs PEP8 and Pyflakes, and can be mapped to any hotkey or action you want in Vim. The plug-in will display errors at the bottom of the screen and provide an easy way to jump to the corresponding line.

If you think it’s handy, you can make Vim call Flake8 every time you save a Python file by adding the following line to your .vimrc:

autocmd BufWritePost *.py call Flake8()

Or, if you are already using syntastic, you can set it to run Pyflakes on write and show errors and warnings in the quickfix window. Here’s an example configuration to do that and also show status and warning messages in the status bar:

set statusline+=%#warningmsg#
set statusline+=%{SyntasticStatuslineFlag()}
set statusline+=%*
let g:syntastic_auto_loc_list=1
let g:syntastic_loc_list_height=5

Emacs

Emacs is another powerful text editor. It now has a GUI but can still be run directly in the console. It is fully programmable (Lisp), and with a little work can be wired up as a Python IDE. Masochists and Raymond Hettinger⁵ use it.

Emacs is written in Lisp and was first released in 1976 by Richard Stallman and Guy L. Steele, Jr. Built-in features include remote edit (via FTP), a calendar, mail send/read, and even a shrink (Esc, then x, then doctor). Popular plug-ins include YASnippet to map custom code snippets to keystrokes, and Tramp for debugging. It is extensible via its own dialect of Lisp, elisp plus.

If you are already an Emacs user, EmacsWiki’s “Python Programming in Emacs” has the best advice for Python packages and configuration. Those new to Emacs can get started with the official Emacs tutorial.

There are three major Python modes for Emacs right now:

• Fabián Ezequiel Gallina’s python.el, now bundled with Emacs (version 24.3+), implements syntax highlighting, indentation, movement, shell interaction, and a number of other common Emacs edit-mode features.

• Jorgen Schäfer’s Elpy aims to provide a full-featured interative development environment within Emacs, including debugging, linters, and code completion.

• Python’s source distribution ships with an alternate version in the directory Misc/python-mode.el. You can download it from the Web as a separate file from launchpad. It has some tools for programming by speech, additional keystroke shortcuts, and allows you to set up a complete Python IDE.

TextMate

TextMate is a GUI with Emacs roots that works only on OS X. It has a truly Apple-worthy user interface that somehow manages to be unobtrusive while exposing all of the commands with minimal discovery effort.

TextMate is written in C++ and was first released in 2004 by Allan Oddgard and Ciarán Walsh. Sublime Text (discussed in “Sublime Text”) can directly import TextMate snippets, and Microsoft’s Code (discussed in “Code”) can directly import TextMate syntax highlighting.

Snippets in any language can be added in bundled groups, and it can otherwise be extended with shell scripts: the user can highlight some text and pipe it as standard input through the script using the Cmd+| (pipe) key combination. The script output replaces the highlighted text.

It has built-in syntax highlighting for Apple’s Swift and Objective C, and (via the Xcode bundle) an interface to xcodebuild. A veteran TextMate user will not have problems coding in Python using this editor. New users who don’t spend much time coding for Apple products are probably better off with the newer cross-platform editors that borrow heavily from TextMate’s best-loved features.

Atom

Atom is a “hackable text editor for the 21st century,” according to the folks at GitHub who created it. It was first released in 2014, is written in CoffeeScript (JavaScript) and Less (CSS), and is built on top of Electron (formerly Atom Shell),⁶ which is GitHub’s application shell based on io.js and Chromium.

Atom is extensible via JavaScript and CSS, and users can add snippets in any language (including TextMate-style snippet definitions). As you’d expect, it has very nice GitHub integration. It comes with native package control and a plethora of packages (2,000+). Recommended for Python development is Linter combined with linter-flake8. Web developers may also like the Atom development server, which runs a small HTTP server and can display the HTML preview within Atom.

Code

Microsoft announced Code in 2015. It is a free, closed source text editor in the Visual Studio family, also built on GitHub’s Electron. It is cross-platform and has key bindings just like TextMate.

It comes with an extension API—check out the VS Code Extension Marketplace to browse existing extensions—and merges what its developers thought were the best parts of TextMate and Atom with Microsoft. It has IntelliSense (code completion) worthy of VisualStudio, and good support for .Net, C#, and F#.

Visual Studio (the sister IDE to the Code text editor) still only works on Windows, even though Code is cross-platform.

PyCharm/IntelliJ IDEA

PyCharm is our favorite Python IDE. The top reasons are its nearly perfect code completion tools, and the quality of its tools for web development. Those in the scientific community recommend the free edition (which doesn’t have the web development tools) as just fine for their needs, but not as often as they choose Spyder (discussed in “Spyder”).

PyCharm is developed by JetBrains, also known for IntelliJ IDEA, a proprietary Java IDE that competes with Eclipse. PyCharm (first released in 2010) and IntelliJ IDEA (first released in 2001) share the same code base, and most of PyCharm’s features can be brought to IntelliJ with the free Python plug-in.

JetBrains recommends PyCharm for a simpler UI, or IntelliJ IDEA if you want to introspect into Jython functions, perform cross-language navigation, or do Java-to-Python refactoring. (PyCharm works with Jython but only as a possible choice for interpreter; the introspection tools aren’t there.) The two are licensed separately—so choose before you buy.

The IntelliJ Community Edition and PyCharm Commuity Edition are open sourced (Apache 2.0 License) and free.

Aptana Studio 3/Eclipse + LiClipse + PyDev

Eclipse is written in Java and was first released in 2001 by IBM as an open, versatile Java IDE. PyDev, the Eclipse plug-in for Python development, was released in 2003 by Aleks Totic, who later passed the torch to Fabio Zadrozny. It is the most popular Eclipse plug-in for Python development.

Although the Eclipse community doesn’t push back online when people advocate for IntelliJ IDEA in forums comparing the two, Eclipse is still the most commonly used Java IDE. This is relevant for Python developers who interface with tools written in Java, as many popular ones (e.g., Hadoop, Spark, and proprietary versions of these) come with instructions and plug-ins for development with Eclipse.

A fork of PyDev is baked into Aptana’s Studio 3, which is an open source suite of plug-ins bundled with Eclipse that provide an IDE for Python (and Django), Ruby (and Rails), HTML, CSS, and PHP. The primary focus of Aptanta’s owner, Appcelerator, is the Appcelerator Studio, a proprietary mobile platform for HTML, CSS, and JavaScript that requires a monthly license (once your app goes live). General PyDev and Python support is there, but is not a priority. That said, if you like Eclipse and are primarily a JavaScript developer making apps for mobile platforms with occasional forays into Python, especially if you use Appcelerator at work, Aptana’s Studio 3 is a good choice.

LiClipse was born out of a desire to have a better multilanguge experience in Eclipse, and easy access to fully dark themes (i.e., in addition to the text background, menus and borders will also be dark). It is a proprietary suite of Eclipse plug-ins written by Zadrozny; part of the license fees (optional) go to keeping PyDev totally free and open source (EPL License; the same as Eclipse). It comes bundled with PyDev, so Python users don’t need to install it themselves.

WingIDE

WingIDE is a Python-specific IDE; probably the second most popular Python IDE after PyCharm. It runs on Linux, Windows, and OS X.

Its debugging tools are very good and include tools to debug Django templates. WingIDE users cite its debugger, the quick learning curve, and a lightweight footprint as reasons they prefer this IDE.

Wing was released in 2000 by Wingware and is written in Python, C, and C++. It supports extensions but does not have a plug-in repository yet, so users have to search for others’ blogs or GitHub accounts to find existing packages.

Spyder

Spyder (an abbreviation of Scientific PYthon Development EnviRonment) is an IDE specifically geared toward working with scientific Python libraries.

Spyder is written in Python by Carlos Córdoba. It is open source (MIT License), and offers code completion, syntax highlighting, a class and function browser, and object inspection. Other features are available via community plug-ins.

Spyder includes integration with pyflakes, pylint, and rope, and comes bundled with NumPy, SciPy, IPython, and Matplotlib. It is itself bundled with the popular Scientific Python distributions Anaconda, Python(x, y), and WinPython.

NINJA-IDE

NINJA-IDE (from the recursive acronym: “Ninja-IDE Is Not Just Another IDE”) is a cross-platform IDE designed to build Python applications. It runs on Linux/X11, Mac OS X, and Windows. Installers for these platforms can be downloaded from NINJA-IDE’s website.

NINJA-IDE is developed in Python and Qt, open sourced (GPLv3 License), and is intentionally lightweight. Out of the box, its best-liked feature is that it highlights problem code when running static code checkers or debugging, and the ability to preview web pages in-browser. It is extensible via Python, and has a plug-in repository. The idea is that users will add only the tools they need.

Development slowed for a while, but a new NINJA-IDE v3 is planned for some time in 2016, and there is still active communication on the NINJA-IDE listserv. The community has many native Spanish speakers, including the core development team.

Komodo IDE

Komodo IDE is developed by ActiveState and is a commercial IDE for Windows, Mac, and Linux. KomodoEdit, the IDE’s text editor, is the open source (Mozilla public license) alternative.

Komodo was first released in 2000 by ActiveState and uses the Mozilla and Scintilla code base. It is extensible via Mozilla add-ons. It suports Python, Perl, Ruby, PHP, Tcl, SQL, Smarty, CSS, HTML, and XML. Komodo Edit does not have a debugger, but one is available as a plug-in. The IDE does not support virtual environments, but does allow the user to select which Python interpreter to use. Django support is not as extensive as in WingIDE, PyCharm, or Eclipse + PyDev.

Eric (the Eric Python IDE)

Eric is open source (GPLv3 licence) with more than 10 years of active development. It is written in Python and based on the Qt GUI toolkit, integrating the Scintilla editor control. It is named after Eric Idle, a member of the Monty Python troupe, and in homage to the IDLE IDE, bundled with Python distributions.

Its features include source code autocompletion, syntax highlighting, support for version control systems, Python 3 support, an integrated web browser, a Python shell, an integrated debugger, and a flexible plug-in system. It does not have extra tools for web frameworks.

Like NINJA-IDE and Komodo IDE, it is intentionally lightweight. Faithful users believe it has the best debugging tools around, including the ability to stop and debug one thread while others continue to run. If you wish to use Matplotlib for interactive plotting in this IDE, you must use the Qt4 backend:

# This must come first:
import matplotlib
matplotlib.use('Qt4Agg')

# And then pyplot will use the Qt4 backend:
import matplotlib.pyplot as plt

This link is to the most recent documentation for the Eric IDE. Users leaving positive notes on Eric IDE’s web page are almost all from the scientific computation (e.g., weather models, or computational fluid dynamics) community.

Visual Studio

Professional programmers who work with Microsoft products on Windows will want Visual Studio. It is written in C++ and C#, and its first version appeared in 1995. In late 2014, the first Visual Studio Community Edition was made available for free for noncommercial developers.

If you intend to work with primarily with enterprise software and use Microsoft products like C# and F#, this is your IDE.

Be sure to install with the Python Tools for Visual Studio (PTVS), which is a checkbox in the list of custom installation options that is by default unchecked. The instructions for installing with Visual Studio or after installing Visual Studio are on the PTVS wiki page.

IDLE

IDLE, which stands for Integrated Development and Learning Environment (and is also the last name of Monty Python member Eric Idle), is part of the Python standard library; it is distributed with Python.

IDLE is completely written in Python by Guido van Rossum (Python’s BDFL—Benevolent Dictator for Life) and uses the Tkinter GUI toolkit. Though IDLE is not suited for full-blown development using Python, it is quite helpful to try out small Python snippets and experiment with different features in Python.

It provides the following features:

• A Python shell window (interpreter)

• A multiwindow text editor that colorizes Python code

• Minimal debugging capability

IPython

IPython provides a rich toolkit to help you make the most out of using Python interactively. Its main components are:

• Powerful Python shells (terminal- and Qt-based)

• A web-based notebook with the same core features as the terminal shell, plus support for rich media, text, code, mathematical expressions, and inline plots

• Support for interactive data visualization (i.e., when configured, your Matplotlib plots pop up in windows) and use of GUI toolkits

• Flexible, embeddable interpreters to load into your own projects

• Tools for high-level and interactive parallel computing

To install IPython, type the following in a terminal shell or in PowerShell:

$ pip install ipython

bpython

bpython is an alternative interface to the Python interpreter for Unix-like operating systems. It has the following features:

• Inline syntax highlighting

• Auto indentation and autocompletion

• Expected parameter list for any Python function

• A “rewind” function to pop the last line of code from memory and re-evaluate it

• The ability to send entered code to a pastebin (to share code online)

• The ability to save entered code to a file

To install bpython, type the following in a terminal shell:

$ pip install bpython

Virtual Environments

A Python virtual environment keeps dependencies required by different projects in separate places. By installing multiple Python environments, your global site-packages directory (where user-installed Python packages are stored) can stay clean and manageable, and you can simultaneously work on a project that, for example, requires Django 1.3 while also maintaining a project that requires Django 1.0.

The virtualenv command does this by creating a separate folder that contains a softlink to the Python executable, a copy of pip, and a place for Python libraries. It prepends that location to the PATH upon activation, and then returns the PATH to its original state when deactivated. It is also possible to use the system-installed version of Python and system-installed libraries, via command-line options.

$ cd my-project-folder
$ virtualenv --python python3 my-venv
$ source my-venv/bin/activate

PS C:\> Set-ExecutionPolicy RemoteSigned

PS C:\> cd my-project-folder
PS C:\> virtualenv --python python3 my-venv
PS C:\> .\my-venv\Scripts\activate

$ pip freeze > requirements.txt

$ pip install -r requirements.txt

$ deactivate

pyenv

pyenv is a tool that allows multiple versions of the Python interpreter to be used at the same time. This solves the problem of having different projects that each require different versions of Python, but you would still need to use virtual environments if the dependency conflict was in the libraries (e.g., requiring different Django versions). For example, you can install Python 2.7 for compatibility in one project, and still use Python 3.5 as the default interpreter. pyenv isn’t just limited to the CPython versions—it will also install PyPy, Anaconda, Miniconda, Stackless, Jython, and IronPython interpreters.

Pyenv works by filling a shims directory with a shim version of the Python interpreter and executables like pip and 2to3. These will be the executables found if the directory is prepended to the $PATH environment variable. A shim is a pass-through function that interprets the current situation and selects the most appropriate function to perform the desired task. For example, when the system looks for a program named python, it looks inside the shims directory first, and uses the shim version, which in turn passes the command on to pyenv. Pyenv then works out which version of Python should be run based on environment variables, *.python-version files, and the global default.

For virtual environments, there is the plug-in pyenv-virtualenv, which automates the creation of different environments, and also makes it possible to use the existing pyenv tools to switch to different environments.

Autoenv

Autoenv provides a lightweight option to manage different environment settings outside of the scope of virtualenv. It overrides the cd shell command so that when you change into a directory containing a .env file (e.g., setting the PATH and an environment variable with a database URL), Autoenv automagically activates the environment, and when you cd out of it, the effect is undone. It does not work in Windows PowerShell.

Install it on Mac OS X using brew:

$ brew install autoenv

or on Linux:

$ git clone git://github.com/kennethreitz/autoenv.git ~/.autoenv
$ echo 'source ~/.autoenv/activate.sh' >> ~/.bashrc

and then open a new terminal shell.

virtualenvwrapper

virtualenvwrapper provides a set of commands that extend Python virtual environments for more control and better manageability. It places all your virtual environments in one directory and provides empty hook functions that can be run before or after creation/activation of the virtual environment or of a project—for example, the hook could set environment variables by sourcing the .env file within a directory.

The problem with placing such functions with the installed items is that the user must somehow acquire these scripts to completely duplicate the environment on another machine. It could be useful on a shared development server, if all of the environments were placed in a shared folder and used by multiple users.

To skip the full virtualenvwrapper installation instructions, first make sure virtualenv is already installed. Then, on OS X or Linux, type the following in a command terminal:

$ pip install virtualenvwrapper

Or use pip install virtualenvwrapper if you are using Python 2, and add this to your ~/.profile:

export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3

and then add the following to you ~/.bash_profile or favorite other shell profile:

source /usr/local/bin/virtualenvwrapper.sh

Finally, close the current terminal window, and open a new one to activate your new profile, and virtualenvwrapper will be available.

On Windows, use virtualenvwrapper-win instead. With virtualenv already installed, type:

PS C:\> pip install virtualenvwrapper-win

Then, on both platforms, the following commands are the most commonly used:

mkvirtualenv my_venv

Creates the virtual environment in the folder ~/.virtualenvs/my_venv. Or on Windows, my_venv will be created in the directory identified by typing %USERPROFILE%\Envs on the command line. The location is customizable via the environment variable $WORKON_HOME.

workon my_venv

Activates the virtual environment or switches from the current environment to the specified one.

deactivate

Deactivates the virtual environment.

rmvirtualenv my_venv

Deletes the virtual environment.

virtualenvwrapper provides tab-completion on environment names, which really helps when you have a lot of environments and have trouble remembering their names. A number of other convenient functions are documented in the full list of virtualenvwrapper commands.

Buildout

Buildout is a Python framework that allows you to create and compose recipes—Python modules containing arbitrary code (usually system calls to make directories or to check out and build source code, and to add non-Python parts to the project, such as a database or a web server). Install it using pip:

$ pip install zc.buildout

Projects that use Buildout would include zc.buildout and the recipes they need in their requirements.txt, or would directly include custom recipes with the source code. They also include the configuration file buildout.cfg, and the bootstrap.py script in its top directory. If you run the script by typing python bootstrap.py, it will read the configuration file to determine which recipes to use, plus each recipe’s configuration options (e.g., the specific compiler flags and library linking flags).

Buildout gives a Python project with non-Python parts portability—another user can reconstruct the same environment. This is different from the script hooks in Virtualenvwrapper, which would need to be copied and transmitted along with the requirements.txt file to be able to re-create a virtual environment.

It includes parts to install eggs,¹⁰ which can be skipped in the newer versions of Python that use wheels instead. See the Buildout tutorial for more information.

Conda

Conda is like pip, virtualenv, and Buildout together. It comes with the Anaconda distribution of Python and is Anaconda’s default package manager. It can be installed via pip:

$ pip install conda

And pip can be installed via conda:

$ conda install pip

The packages are stored on different repositories (pip pulls from http://pypi.python.org, and conda pulls from https://repo.continuum.io/), and they use different formats, so the tools are not interchangeable.

conda-build, Continuum’s analogue to Buildout, can be installed on all platforms by typing:

conda install conda-build

Like with Buildout, the conda-build configuration file format is called a “recipe,” and the recipes are not limited to using Python tools. Unlike Buildout, the code is specified in shell script, not Python, and the configuration is specified in YAML,¹¹ not Python’s ConfigParser format.

The main advantage of conda over pip and virtualenv is for Windows users—Python libraries built as C extensions may or may not be present as wheels, but they are almost always present on the Anaconda package index. And if a package is not available via conda, it is possible to install pip and then install packages hosted on PyPI.

Docker

Docker helps with environment isolation like virtualenv, conda, or Buildout, but instead of providing a virtual environment, it provides a Docker container. Containers provide greater isolation than environments. For example, you can have containers running, each with different network interfaces, firewalling rules, and a different hostname. These running containers are managed by a separate utility, the Docker Engine, that coordinates access to the underlying operating system. If you’re running Docker containers on OS X, Windows, or on a remote host, you’ll also need Docker Machine, which interfaces with the virtual machine(s)¹² that will run the Docker Engine.

Docker containers were originally based on Linux Containers, which were themselves originally related to the shell command chroot. chroot is kind of a system-level version of the virtualenv command: it makes it appear that the root directory (/) is at a user-specified path instead of the actual root, providing a completely separate user space.

Docker doesn’t use chroot, and it doesn’t even use Linux Containers anymore (allowing the universe of Docker images to include Citrix and Solaris machines), but the Docker Containers are still doing about the same thing. Its configuration files are called Dockerfiles, which build Docker images that can then be hosted on the Docker Hub, the Docker package repository (like PyPI).

Docker images, when configured correctly, can take up less space than environments created using Buildout or conda because Docker users the AUFS union file system, which stores the “diff” of an image, instead of the whole image. So, for example, if you want to build and test your package against multiple releases of a dependency, you could make a base Docker image that contains a virtual environment¹³ (or Buildout environment, or conda environment) containing all of the other dependencies. You’d then inherit from that base for all of your other images, adding only the single changing dependency in the last layer. Then, all of the derived containers will contain only the different new library, sharing the contents of the base image. For more information, see the Docker documentation.