Ipython Docs Readthedocs Io en Latest
Ipython Docs Readthedocs Io en Latest
Release 3.0.0-dev
1 Introduction 3
3 Installation 249
Bibliography 515
i
ii
IPython Documentation, Release 3.0.0-dev
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Contents 1
IPython Documentation, Release 3.0.0-dev
2 Contents
CHAPTER 1
Introduction
Overview
One of Python’s most useful features is its interactive interpreter. It allows for very fast testing of ideas
without the overhead of creating test files as is typical in most programming languages. However, the
interpreter supplied with the standard Python distribution is somewhat limited for extended interactive use.
The goal of IPython is to create a comprehensive environment for interactive and exploratory computing.
To support this goal, IPython has three main components:
• An enhanced interactive Python shell.
• A decoupled two-process communication model, which allows for multiple clients to connect to a
computation kernel, most notably the web-based notebook
• An architecture for interactive parallel computing.
All of IPython is open source (released under the revised BSD license).
IPython’s interactive shell (ipython), has the following goals, amongst others:
1. Provide an interactive shell superior to Python’s default. IPython has many features for tab-
completion, object introspection, system shell access, command history retrieval across sessions, and
its own special command system for adding functionality when working interactively. It tries to be a
very efficient environment both for Python code development and for exploration of problems using
Python objects (in situations like data analysis).
2. Serve as an embeddable, ready to use interpreter for your own programs. An interactive IPython
shell can be started with a single call from inside another program, providing access to the current
3
IPython Documentation, Release 3.0.0-dev
namespace. This can be very useful both for debugging purposes and for situations where a blend of
batch-processing and interactive exploration are needed.
3. Offer a flexible framework which can be used as the base environment for working with other systems,
with Python as the underlying bridge language. Specifically scientific environments like Mathematica,
IDL and Matlab inspired its design, but similar ideas can be useful in many fields.
4. Allow interactive testing of threaded graphical toolkits. IPython has support for interactive, non-
blocking control of GTK, Qt, WX, GLUT, and OS X applications via special threading flags. The
normal Python shell can only do this for Tkinter applications.
• Dynamic object introspection. One can access docstrings, function definition prototypes, source code,
source files and other details of any object accessible to the interpreter with a single keystroke (?, and
using ?? provides additional detail).
• Searching through modules and namespaces with * wildcards, both when using the ? system and via
the %psearch command.
• Completion in the local namespace, by typing TAB at the prompt. This works for keywords, modules,
methods, variables and files in the current directory. This is supported via the readline library, and full
access to configuring readline’s behavior is provided. Custom completers can be implemented easily
for different purposes (system commands, magic arguments etc.)
• Numbered input/output prompts with command history (persistent across sessions and tied to each
profile), full searching in this history and caching of all input and output.
• User-extensible ‘magic’ commands. A set of commands prefixed with % is available for controlling
IPython itself and provides directory control, namespace information and many aliases to common
system shell commands.
• Alias facility for defining your own system aliases.
• Complete system shell access. Lines starting with ! are passed directly to the system shell, and using
!! or var = !cmd captures shell output into python variables for further use.
• The ability to expand python variables when calling the system shell. In a shell command, any python
variable prefixed with $ is expanded. A double $$ allows passing a literal $ to the shell (for access
to shell and environment variables like PATH).
• Filesystem navigation, via a magic %cd command, along with a persistent bookmark system (using
%bookmark) for fast access to frequently visited directories.
• A lightweight persistence framework via the %store command, which allows you to save arbitrary
Python variables. These get restored when you run the %store -r command.
• Automatic indentation (optional) of code as you type (through the readline library).
• Macro system for quickly re-executing multiple lines of previous input with a single name via the
%macro command. Macros can be stored persistently via %store and edited via %edit.
4 Chapter 1. Introduction
IPython Documentation, Release 3.0.0-dev
• Session logging (you can then later use these logs as code in your programs). Logs can optionally
timestamp all input, and also store session output (marked as comments, so the log remains valid
Python source code).
• Session restoring: logs can be replayed to restore a previous session to the state where you left it.
• Verbose and colored exception traceback printouts. Easier to parse visually, and in verbose mode they
produce a lot of useful debugging information (basically a terminal version of the cgitb module).
• Auto-parentheses via the %autocall command: callable objects can be executed without parenthe-
ses: sin 3 is automatically converted to sin(3)
• Auto-quoting: using ,, or ; as the first character forces auto-quoting of the rest of the
line: ,my_function a b becomes automatically my_function("a","b"), while ;
my_function a b becomes my_function("a b").
• Extensible input syntax. You can define filters that pre-process user input to simplify input in special
situations. This allows for example pasting multi-line code fragments which start with >>> or ...
such as those from other python sessions or the standard Python documentation.
• Flexible configuration system. It uses a configuration file which allows permanent setting of all
command-line options, module loading, code and file execution. The system allows recursive file
inclusion, so you can have a base file with defaults and layers which load other customizations for
particular projects.
• Embeddable. You can call IPython as a python shell inside your own python programs. This can be
used both for debugging code or for providing interactive abilities to your programs with knowledge
about the local namespaces (very useful in debugging and data analysis situations).
• Easy debugger access. You can set IPython to call up an enhanced version of the Python debugger
(pdb) every time there is an uncaught exception. This drops you inside the code which triggered the
exception with all the data live and it is possible to navigate the stack to rapidly isolate the source
of a bug. The %run magic command (with the -d option) can run any script under pdb’s control,
automatically setting initial breakpoints for you. This version of pdb has IPython-specific improve-
ments, including tab-completion and traceback coloring support. For even easier debugger access, try
%debug after seeing an exception.
• Profiler support. You can run single statements (similar to profile.run()) or complete programs
under the profiler’s control. While this is possible with standard cProfile or profile modules, IPython
wraps this functionality with magic commands (see %prun and %run -p) convenient for rapid
interactive work.
• Simple timing information. You can use the %timeit command to get the execution time of a Python
statement or expression. This machinery is intelligent enough to do more repetitions for commands
that finish very quickly in order to get a better estimate of their running time.
To get the timing information for more than one expression, use the %%timeit cell magic
command.
• Doctest support. The special %doctest_mode command toggles a mode to use doctest-compatible
prompts, so you can use IPython sessions as doctest code. By default, IPython also allows you to
paste existing doctests, and strips out the leading >>> and ... prompts in them.
IPython has abstracted and extended the notion of a traditional Read-Evaluate-Print Loop (REPL) environ-
ment by decoupling the evaluation into its own process. We call this process a kernel: it receives execution
instructions from clients and communicates the results back to them.
This decoupling allows us to have several clients connected to the same kernel, and even allows clients and
kernels to live on different machines. With the exclusion of the traditional single process terminal-based
IPython (what you start if you run ipython without any subcommands), all other IPython machinery uses
this two-process model. This includes ipython console, ipython qtconsole, and ipython
notebook.
As an example, this means that when you start ipython qtconsole, you’re really starting two pro-
cesses, a kernel and a Qt-based client can send commands to and receive results from that kernel. If there
is already a kernel running that you want to connect to, you can pass the --existing flag which will
skip initiating a new kernel and connect to the most recent kernel, instead. To connect to a specific kernel
once you have several kernels running, use the %connect_info magic to get the unique connection file,
which will be something like --existing kernel-19732.json but with different numbers which
correspond to the Process ID of the kernel.
You can read more about using ipython qtconsole, and ipython notebook. There is also a message spec which
documents the protocol for communication between kernels and clients.
See also:
Frontend/Kernel Model example notebook
Increasingly, parallel computer hardware, such as multicore CPUs, clusters and supercomputers, is becom-
ing ubiquitous. Over the last several years, we have developed an architecture within IPython that allows
such hardware to be used quickly and easily from Python. Moreover, this architecture is designed to support
interactive and collaborative parallel computing.
The main features of this system are:
• Quickly parallelize Python code from an interactive Python/IPython session.
• A flexible and dynamic process model that be deployed on anything from multicore workstations to
supercomputers.
• An architecture that supports many different styles of parallelism, from message passing to task farm-
ing. And all of these styles can be handled interactively.
6 Chapter 1. Introduction
IPython Documentation, Release 3.0.0-dev
As of the 2.0 release, IPython works with Python 2.7 and 3.3 or above. Version 1.0 additionally worked with
Python 2.6 and 3.2. Version 0.12 was the first version to fully support Python 3.
IPython is known to work on the following operating systems:
• Linux
• Most other Unix-like OSs (AIX, Solaris, BSD, etc.)
• Mac OS X
• Windows (CygWin, XP, Vista, etc.)
See here for instructions on how to install IPython.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
8 Chapter 1. Introduction
CHAPTER 2
This section documents the changes that have been made in various versions of IPython. Users should
consult these pages to learn about new features, bug fixes and backwards incompatibilities. Developers
should summarize the development work they do here in a user friendly format.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Development version
Warning: Please do not edit this file by hand (doing so will likely cause merge conflicts for other Pull
Requests). Instead, create a new file in the docs/source/whatsnew/pr folder
9
IPython Documentation, Release 3.0.0-dev
You can now choose a kernel for a notebook within the user interface, rather than starting up a separate
notebook server for each kernel you want to use. The syntax highlighting adapts to match the language
you’re working in.
Information about the kernel is stored in the notebook file, so when you open a notebook, it will automati-
cally start the correct kernel.
It is also easier to use the Qt console and the terminal console with other kernels, using the –kernel flag:
Kernel authors should see Kernel specs for how to register their kernels with IPython so that these mecha-
nisms work.
Complex expressions can be much cleaner when written with a wider choice of characters. Python 3 allows
unicode identifiers, and IPython 3 makes it easier to type those, using a feature from Julia. Type a backslash
followed by a LaTeX style short name, such as \alpha. Press tab, and it will turn into 𝛼.
• TextWidget and TextareaWidget objects now include a placeholder attribute, for display-
ing placeholder text before the user has typed anything.
• The %load magic can now find the source for objects in the user namespace. To enable searching the
namespace, use the -n option.
• DirectView objects have a new use_cloudpickle() method, which works like view.
use_dill(), but causes the cloudpickle module from PiCloud’s cloud library to be used rather
than dill or the builtin pickle module.
• Added a .ipynb exporter to nbconvert. It can be used by passing --to notebook as a commandline
argument to nbconvert.
• New nbconvert preprocessor called ClearOutputPreprocessor. This clears the output from
IPython notebooks.
• New preprocessor for nbconvert that executes all the code cells in a notebook. To run a notebook and
save its output in a new notebook:
• Consecutive stream (stdout/stderr) output is merged into a single output in the notebook document.
Previously, all output messages were preserved as separate output fields in the JSON. Now, the same
merge is applied to the stored output as the displayed output, improving document load time for
notebooks with many small outputs.
• NotebookApp.webapp_settings is deprecated and replaced with the more informatively
named NotebookApp.tornado_settings.
• Using %timeit prints warnings if there is atleast a 4x difference in timings between the slowest and
fastest runs, since this might meant that the multiple runs are not independent of one another.
• It’s now possible to provide mechanisms to integrate IPython with other event loops, in addition to
the ones we already support. This lets you run GUI code in IPython with an interactive prompt, and to
embed the IPython kernel in GUI applications. See Integrating with GUI event loops for details. As
part of this, the direct enable_* and disable_* functions for various GUIs in IPython.lib.
inputhook have been deprecated in favour of enable_gui() and disable_gui().
• A ScrollManager was added to the notebook. The ScrollManager controls how the note-
book document is scrolled using keyboard. Users can inherit from the ScrollManager or
TargetScrollManager to customize how their notebook scrolls. The default ScrollManager
is the SlideScrollManager, which tries to scroll to the nearest slide or sub-slide cell.
• The function interact_manual() has been added which behaves similarly to interact(),
but adds a button to explicitly run the interacted-with function, rather than doing it automatically for
every change of the parameter widgets. This should be useful for long-running functions.
• The %cython magic is now part of the Cython module. Use %load_ext Cython with a version
of Cython >= 0.21 to have access to the magic now.
• The Notebook application now offers integrated terminals on Unix platforms, intended for when it is
used on a remote server. To enable these, install the terminado Python package.
• Setting the default highlighting language for nbconvert with the config option NbConvertBase.
default_language is deprecated. Nbconvert now respects metadata stored in the kernel spec.
• IPython can now be configured systemwide, with files in /etc/ipython or /usr/local/etc/
ipython on Unix systems, or %PROGRAMDATA%\ipython on Windows.
• The NotebookManager and /api/notebooks service has been replaced by a more generic Con-
tentsManager and /api/contents service, which supports all kinds of files.
• The Dashboard now lists all files, not just notebooks and directories.
• The --script hook for saving notebooks to Python scripts is removed, use ipython
nbconvert --to python notebook instead.
• The rmagic extension is deprecated, as it is now part of rpy2. See rpy2.ipython.rmagic.
• start_kernel() and format_kernel_cmd() no longer accept a executable parameter.
Use the kernelspec machinery instead.
• The widget classes have been renamed from *Widget to *. The old names are still functional, but
are deprecated. i.e. IntSliderWidget has been renamed to IntSlider.
• The ContainerWidget was renamed to Box and no longer defaults as a flexible box in the web browser.
A new FlexBox widget was added, which allows you to use the flexible box model.
The Content Security Policy is a web standard for adding a layer of security to detect and mitigate certain
classes of attacks, including Cross Site Scripting (XSS) and data injection attacks. This was introduced into
the notebook to ensure that the IPython Notebook and its APIs (by default) can only be embedded in an
iframe on the same origin.
Override headers['Content-Security-Policy'] within your notebook configuration to extend
for alternate domains and security settings.:
c.NotebookApp.tornado_settings = {
'headers': {
'Content-Security-Policy': "frame-ancestors 'self'"
}
}
Example policies:
Matches embeddings on any subdomain of jupyter.org, so long as they are served over SSL.
There is a report-uri endpoint available for logging CSP violations, located at /api/security/
csp-report. To use it, set report-uri as part of the CSP:
c.NotebookApp.tornado_settings = {
'headers': {
'Content-Security-Policy': "frame-ancestors 'self'; report-uri /api/
˓→security/csp-report"
}
}
It simply provides the CSP report as a warning in IPython’s logs. The default CSP sets this report-uri relative
to the base_url (not shown above).
For a more thorough and accurate guide on Content Security Policies, check out MDN’s Using Content
Security Policy for more examples.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
2.0 Series
Release 2.1.0
May, 2014
IPython 2.1 is the first bugfix release for 2.0. For more information on what fixes have been backported to
2.1, see our detailed release info.
Release 2.0.0
April, 2014
IPython 2.0 requires Python 2.7.2 or 3.3.0. It does not support Python 3.0, 3.1, 3.2, 2.5, or 2.6.
The principal milestones of 2.0 are:
• interactive widgets for the notebook
• directory navigation in the notebook dashboard
• persistent URLs for notebooks
• a new modal user interface in the notebook
• a security model for notebooks
Contribution summary since IPython 1.0 in August, 2013:
• ~8 months of work
• ~650 pull requests merged
• ~400 issues closed (non-pull requests)
• contributions from ~100 authors
• ~4000 commits
The amount of work included in this release is so large that we can only cover here the main highlights;
please see our detailed release statistics for links to every issue and pull request closed on GitHub as well
as a full list of individual contributors.
Directory navigation
The IPython notebook dashboard allows navigation into subdirectories. URLs are persistent based on the
notebook’s path and name, so no more random UUID URLs.
Serving local files no longer needs the files/ prefix. Relative links across notebooks and other files
should work just as if notebooks were regular HTML files.
Interactive widgets
IPython 2.0 adds IPython.html.widgets, for manipulating Python objects in the kernel with GUI
controls in the notebook. IPython comes with a few built-in widgets for simple data types, and an API
designed for developers to build more complex widgets. See the widget docs for more information.
The notebook has added separate Edit and Command modes, allowing easier keyboard commands and mak-
ing keyboard shortcut customization possible. See the new User Interface notebook for more information.
You can familiarize yourself with the updated notebook user interface, including an explanation of Edit and
Command modes, by going through the short guided tour which can be started from the Help menu.
Security
2.0 introduces a security model for notebooks, to prevent untrusted code from executing on users’ behalf
when notebooks open. A quick summary of the model:
• Trust is determined by signing notebooks.
• Untrusted HTML output is sanitized.
• Untrusted Javascript is never executed.
• HTML and Javascript in Markdown are never trusted.
The dashboard now has a “Running” tab which shows all of the running notebooks.
IPython previously supported Python 3 by running 2to3 during setup. We have now switched to a single
codebase which runs natively on Python 2.7 and 3.3.
For notes on how to maintain this, see Writing code for Python 2 and 3.
clear_output changes
Some configurable traits are containers (list, dict, set) Config objects now support calling extend,
update, insert, etc. on traits in config files, which will ultimately result in calling those methods
on the original object.
The effect being that you can now add to containers without having to copy/paste the initial value:
c = get_config()
c.InlineBackend.rc.update({ 'figure.figsize' : (6, 4) })
Previously, all names declared in code run at startup (startup files, ipython -i script.py, etc.) were
added to the hidden namespace, which hides the names from tools like %whos. There are two changes to
this behavior:
1. Scripts run on the command-line ipython -i script.py``now behave the same as
if they were passed to ``%run, so their variables are never hidden.
The new function use_dill() allows dill to extend serialization support in IPython.parallel (clo-
sures, etc.). A DirectView.use_dill() convenience method was also added, to enable dill locally
and on all engines with one call.
The IPython console lexer has been rewritten and now supports tracebacks and customized input/output
prompts. See the new lexer docs for details.
DisplayFormatter changes
There was no official way to query or remove callbacks in the Formatter API. To remedy this, the following
methods are added to BaseFormatter:
• lookup(instance) - return appropriate callback or a given object
• lookup_by_type(type_or_str) - return appropriate callback for a given type or 'mod.
name' type string
• pop(type_or_str) - remove a type (by type or string). Pass a second argument to avoid KeyError
(like dict).
All of the above methods raise a KeyError if no match is found.
And the following methods are changed:
• for_type(type_or_str) - behaves the same as before, only adding support for 'mod.name'
type strings in addition to plain types. This removes the need for for_type_by_name(), but it
remains for backward compatibility.
Formatters can now raise NotImplementedError in addition to returning None to indicate that they cannot
format a given object.
Exceptions are no longer silenced when formatters fail. Instead, these are turned into a
FormatterWarning. A FormatterWarning will also be issued if a formatter returns data of an invalid
type (e.g. an integer for ‘image/png’).
Other changes
• %%capture cell magic now captures the rich display output, not just stdout/stderr
• In notebook, Showing tooltip on tab has been disables to avoid conflict with completion, Shift-Tab
could still be used to invoke tooltip when inside function signature and/or on selection.
• object_info_request has been replaced by object_info for consistency in the javascript
API. object_info is a simpler interface to register callback that is incompatible with
object_info_request.
• Previous versions of IPython on Linux would use the XDG config directory, creating ~/.config/
ipython by default. We have decided to go back to ~/.ipython for consistency among systems.
IPython will issue a warning if it finds the XDG location, and will move it to the new location if there
isn’t already a directory there.
• Equations, images and tables are now centered in Markdown cells.
• Multiline equations are now centered in output areas; single line equations remain left justified.
• IPython config objects can be loaded from and serialized to JSON. JSON config file have the same
base name as their .py counterpart, and will be loaded with higher priority if found.
• bash completion updated with support for all ipython subcommands and flags, including nbconvert
• ipython history trim: added --keep=<N> as an alias for the more verbose
--HistoryTrim.keep=<N>
• New ipython history clear subcommand, which is the same as the newly supported
ipython history trim --keep=0
• You can now run notebooks in an interactive session via %run notebook.ipynb.
• Print preview is back in the notebook menus, along with options to download the open notebook in
various formats. This is powered by nbconvert.
• PandocMissing exceptions will be raised if Pandoc is unavailable, and warnings will be printed if
the version found is too old. The recommended Pandoc version for use with nbconvert is 1.12.1.
• The InlineBackend.figure_format now supports JPEG output if PIL/Pillow is available.
• Input transformers (see Custom input transformation) may now raise SyntaxError if they deter-
mine that input is invalid. The input transformation machinery in IPython will handle displaying the
exception to the user and resetting state.
• Calling container.show() on javascript display is deprecated and will trigger errors on future
IPython notebook versions. container now show itself as soon as non-empty
• Added InlineBackend.print_figure_kwargs to allow passing keyword arguments to mat-
plotlib’s Canvas.print_figure. This can be used to change the value of bbox_inches, which
is ‘tight’ by default, or set the quality of JPEG figures.
• A new callback system has been introduced. For details, see Registering callbacks.
• jQuery and require.js are loaded from CDNs in the default HTML template, so javascript is available
in static HTML export (e.g. nbviewer).
• Python 2.6 and 3.2 are no longer supported: the minimum required Python versions are now 2.7 and
3.3.
• The Transformer classes have been renamed to Preprocessor in nbconvert and their call methods
have been renamed to preprocess.
• The call methods of nbconvert post-processsors have been renamed to postprocess.
• The module IPython.core.fakemodule has been removed.
• The alias system has been reimplemented to use magic functions. There should be little visible dif-
ference while automagics are enabled, as they are by default, but parts of the AliasManager API
have been removed.
• We fixed an issue with switching between matplotlib inline and GUI backends, but the fix requires
matplotlib 1.1 or newer. So from now on, we consider matplotlib 1.1 to be the minimally supported
version for IPython. Older versions for the most part will work, but we make no guarantees about it.
• The pycolor command has been removed. We recommend the much more capable pygmentize
command from the Pygments project. If you need to keep the exact output of pycolor, you can still
use python -m IPython.utils.PyColorize foo.py.
• IPython.lib.irunner and its command-line entry point have been removed. It had fallen out
of use long ago.
• The input_prefilter hook has been removed, as it was never actually used by the code. The
input transformer system offers much more powerful APIs to work with input code. See Custom input
transformation for details.
• IPython.core.inputsplitter.IPythonInputSplitter no longer has a method
source_raw_reset(), but gains raw_reset() instead. Use of source_raw_reset can
be replaced with:
raw = isp.source_raw
transformed = isp.source_reset()
• The Azure notebook manager was removed as it was no longer compatible with the notebook storage
scheme.
• Simplifying configurable URLs
– base_project_url is renamed to base_url (base_project_url is kept as a deprecated alias, for now)
– base_kernel_url configurable is removed (use base_url)
– websocket_url configurable is removed (use base_url)
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
• Raffaele De Feo
• Renaud Richardet
• Spencer Nelson
• Steve Chan
• sunny
• Susan Tan
• Thomas Kluyver
• Yaroslav Halchenko
• zah
We closed a total of 129 issues, 92 pull requests and 37 regular issues; this is the full list (generated with the
script tools/github_stats.py --milestone 2.1):
Pull Requests (92):
• PR #5871: specify encoding in msgpack.unpackb
• PR #5869: Catch more errors from clipboard access on Windows
• PR #5866: Make test robust against differences in line endings
• PR #5605: Two cell toolbar fixes.
• PR #5843: remove Firefox-specific CSS workaround
• PR #5845: Pass Windows interrupt event to kernels as an environment variable
• PR #5835: fix typo in v2 convert
• PR #5841: Fix writing history with output to a file in Python 2
• PR #5842: fix typo in nbconvert help
• PR #5846: Fix typos in Cython example
• PR #5839: Close graphics dev in finally clause
• PR #5837: pass on install docs
• PR #5832: Fixed example to work with python3
• PR #5826: allow notebook tour instantiation to fail
• PR #5560: Minor expansion of Cython example
• PR #5818: interpret any exception in getcallargs as not callable
• PR #5816: Add output to IPython directive when in verbatim mode.
• PR #5822: Don’t overwrite widget description in interact
• PR #5782: Silence exception thrown by completer when dir() does not return a list
• PR #5807: Drop log level to info for Qt console shutdown
• Bradley M. Froehle
• Brian E. Granger
• Carlos Cordoba
• chapmanb
• chebee7i
• Christoph Gohlke
• Christophe Pradal
• Cyrille Rossant
• Damián Avila
• Daniel B. Vasquez
• Dav Clark
• David Hirschfeld
• David P. Sanders
• David Wyde
• David Österberg
• Doug Blank
• Dražen Lučanin
• epifanio
• Fernando Perez
• Gabriel Becker
• Geert Barentsen
• Hans Meine
• Ingolf Becker
• Jake Vanderplas
• Jakob Gager
• James Porter
• Jason Grout
• Jeffrey Tratner
• Jonah Graham
• Jonathan Frederic
• Joris Van den Bossche
• Juergen Hasch
• Julian Taylor
• Katie Silverio
• Kevin Burke
• Kieran O’Mahony
• Konrad Hinsen
• Kyle Kelley
• Lawrence Fu
• Marc Molla
• Martín Gaitán
• Matt Henderson
• Matthew Brett
• Matthias Bussonnier
• Michael Droettboom
• Mike McKerns
• Nathan Goldbaum
• Pablo de Oliveira
• Pankaj Pandey
• Pascal Schetelat
• Paul Ivanov
• Paul Moore
• Pere Vilas
• Peter Davis
• Philippe Mallet-Ladeira
• Preston Holmes
• Puneeth Chaganti
• Richard Everson
• Roberto Bonvallet
• Samuel Ainsworth
• Sean Vig
• Shashi Gowda
• Skipper Seabold
• Stephan Rave
• Steve Fox
• Steven Silvester
• stonebig
• Susan Tan
• Sylvain Corlay
• Takeshi Kanmae
• Ted Drain
• Thomas A Caswell
• Thomas Kluyver
• Théophile Studer
• Volker Braun
• Wieland Hoffmann
• Yaroslav Halchenko
• Yoval P.
• Yung Siang Liau
• Zachary Sailer
• zah
We closed a total of 1121 issues, 687 pull requests and 434 regular issues; this is the full list (generated with
the script tools/github_stats.py):
Pull Requests (687):
• PR #5487: remove weird unicode space in the new copyright header
• PR #5476: For 2.0: Fix links in Notebook Help Menu
• PR #5337: Examples reorganization
• PR #5436: CodeMirror shortcuts in QuickHelp
• PR #5444: Fix numeric verification for Int and Float text widgets.
• PR #5449: Stretch keyboard shortcut dialog
• PR #5473: Minor corrections of git-hooks setup instructions
• PR #5471: Add coding magic comment to nbconvert Python template
• PR #5452: print_figure returns unicode for svg
• PR #5450: proposal: remove codename
• PR #5462: DOC : fixed minor error in using topological sort
• PR #5463: make spin_thread tests more forgiving of slow VMs
• PR #5091: Provide logging messages in ipcluster log when engine or controllers fail to start
• PR #5090: Print a warning when iptest is run from the IPython source directory
• PR #5077: flush replies when entering an eventloop
• PR #5055: Minimal changes to import IPython from IronPython
• PR #5078: Updating JS tests README.md
• PR #5083: don’t create js test directories unless they are being used
• PR #5062: adjust some events in nb_roundtrip
• PR #5043: various unicode / url fixes
• PR #5066: remove (almost) all mentions of pylab from our examples
• PR #4977: ensure scp destination directories exist (with mkdir -p)
• PR #5053: Move&rename JS tests
• PR #5067: show traceback in widget handlers
• PR #4920: Adding PDFFormatter and kernel side handling of PDF display data
• PR #5048: Add edit/command mode indicator
• PR #5061: make execute button in menu bar match shift-enter
• PR #5052: Add q to toggle the pager.
• PR #5070: fix flex: auto
• PR #5065: Add example of using annotations in interact
• PR #5063: another pass on Interact example notebooks
• PR #5051: FF Fix: code cell missing hscroll (2)
• PR #4960: Interact/Interactive for widget
• PR #5045: Clear timeout in multi-press keyboard shortcuts.
• PR #5060: Change ‘bind’ to ‘link’
• PR #5039: Expose kernel_info method on inprocess kernel client
• PR #5058: Fix iopubwatcher.py example script.
• PR #5035: FF Fix: code cell missing hscroll
• PR #5040: Polishing some docs
• PR #5001: Add directory navigation to dashboard
• PR #5042: Remove duplicated Channel ABC classes.
• PR #5036: FF Fix: ext link icon same line as link text in help menu
• PR #4975: setup.py changes for 2.0
• PR #4774: emit event on appended element on dom
• PR #4092: nbconvert: Fix for unicode html headers, Windows + Python 2.x
• PR #4074: close Client sockets if connection fails
• PR #4064: Store default codemirror mode in only 1 place
• PR #4104: Add way to install MathJax to a particular profile
• PR #4161: Select name when renaming a notebook
• PR #4160: Add quotes around ”.[notebook]” in readme
• PR #4144: help_end transformer shouldn’t pick up ? in multiline string
• PR #4090: Add LaTeX citation handling to nbconvert
• PR #4143: update example custom.js
• PR #4142: DOC: unwrap openssl line in public_server doc
• PR #4126: update tox.ini
• PR #4141: add files with a separate add call in backport_pr
• PR #4137: Restore autorestore option for storemagic
• PR #4098: pass profile-dir instead of profile name to Kernel
• PR #4120: support input in Python 2 kernels
• PR #4088: nbconvert: Fix coalescestreams line with incorrect nesting causing strange behavior
• PR #4060: only strip continuation prompts if regular prompts seen first
• PR #4132: Fixed name error bug in function safe_unicode in module py3compat.
• PR #4121: move test_kernel from IPython.zmq to IPython.kernel
• PR #4118: ZMQ heartbeat channel: catch EINTR exceptions and continue.
• PR #4070: New changes should go into pr/ folder
• PR #4054: use unicode for HTML export
• PR #4106: fix a couple of default block values
• PR #4107: update parallel magic tests with capture_output API
• PR #4102: Fix clashes between debugger tests and coverage.py
• PR #4115: Update docs on declaring a magic function
• PR #4101: restore accidentally removed EngineError
• PR #4096: minor docs changes
• PR #4094: Update target branch before backporting PR
• PR #4069: Drop monkeypatch for pre-1.0 nose
• PR #4056: respect pylab_import_all when --pylab specified at the command-line
• PR #4091: Make Qt console banner configurable
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
1.0 Series
IPython 1.0 requires Python 2.6.5 or 3.2.1. It does not support Python 3.0, 3.1, or 2.5.
This is a big release. The principal milestone is the addition of IPython.nbconvert, but there has been
a great deal of work improving all parts of IPython as well.
The previous version (0.13) was released on June 30, 2012, and in this development cycle we had:
• ~12 months of work.
• ~700 pull requests merged.
• ~600 issues closed (non-pull requests).
• contributions from ~150 authors.
• ~4000 commits.
The amount of work included in this release is so large that we can only cover here the main highlights;
please see our detailed release statistics for links to every issue and pull request closed on GitHub as well
as a full list of individual contributors. It includes
Reorganization
Public APIs
For the first time since 0.10 (sorry, everyone), there is an official public API for starting IPython:
This is what packages should use that start their own IPython session, but don’t actually want embedded
IPython (most cases). IPython.embed() is used for embedding IPython into the calling namespace,
similar to calling Pdb.set_trace(), whereas start_ipython() will start a plain IPython session,
loading config and startup files as normal.
We also have added:
Which is a library function for getting the current IPython instance, and will return None if no IPython
instance is running. This is the official way to check whether your code is called from inside an IPython
session. If you want to check for IPython without unnecessarily importing IPython, use this function:
def get_ipython():
"""return IPython instance if there is one, None otherwise"""
import sys
if "IPython" in sys.modules:
import IPython
return IPython.get_ipython()
Core
• The input transformation framework has been reworked. This fixes some corner cases, and adds more
flexibility for projects which use IPython, like SymPy & SAGE. For more details, see Custom input
transformation.
• Exception types can now be displayed with a custom traceback, by defining a
_render_traceback_() method which returns a list of strings, each containing one line
of the traceback.
• A new command, ipython history trim can be used to delete everything but the last 1000
entries in the history database.
• __file__ is defined in both config files at load time, and .ipy files executed with %run.
• %logstart and %logappend are no longer broken.
• Add glob expansion for %run, e.g. %run -g script.py *.txt.
• Expand variables ($foo) in Cell Magic argument line.
• By default, iptest will exclude various slow tests. All tests can be run with iptest --all.
• SQLite history can be disabled in the various cases that it does not behave well.
• %edit works on interactively defined variables.
• editor hooks have been restored from quarantine, enabling TextMate as editor, etc.
• The env variable PYTHONSTARTUP is respected by IPython.
• The %matplotlib magic was added, which is like the old %pylab magic, but it does not import
anything to the interactive namespace. It is recommended that users switch to %matplotlib and
explicit imports.
• The --matplotlib command line flag was also added. It invokes the new %matplotlib
magic and can be used in the same way as the old --pylab flag. You can either use it by itself
as a flag (--matplotlib), or you can also pass a backend explicitly (--matplotlib qt or
--matplotlib=wx, etc).
NbConvert
The major milestone for IPython 1.0 is the addition of IPython.nbconvert - tools for converting
IPython notebooks to various other formats.
See ipython nbconvert --help for more information. nbconvert depends on pandoc for many of
the translations to and from various formats.
See also:
Converting notebooks to other formats
Notebook
• The Print View has been removed. Users are encouraged to test ipython nbconvert to generate a static
view.
Javascript Components
The javascript components used in the notebook have been updated significantly.
• updates to jQuery (2.0) and jQueryUI (1.10)
• Update CodeMirror to 3.14
• Twitter Bootstrap (2.3) for layout
• Font-Awesome (3.1) for icons
• highlight.js (7.3) for syntax highlighting
• marked (0.2.8) for markdown rendering
• require.js (2.1) for loading javascript
Some relevant changes that are results of this:
• Markdown cells now support GitHub-flavored Markdown (GFM), which includes ```python code
blocks and tables.
• Notebook UI behaves better on more screen sizes.
• Various code cell input issues have been fixed.
Kernel
IPEP 13
The KernelManager has been split into a KernelManager and a KernelClient. The Manager owns
a kernel and starts / signals / restarts it. There is always zero or one KernelManager per Kernel. Clients
communicate with Kernels via zmq channels, and there can be zero-to-many Clients connected to a Kernel
at any given time.
The KernelManager now automatically restarts the kernel when it dies, rather than requiring user input at
the notebook or QtConsole UI (which may or may not exist at restart time).
In-process kernels
The Python-language frontends, particularly the Qt console, may now communicate with in-process kernels,
in addition to the traditional out-of-process kernels. An in-process kernel permits direct access to the kernel
namespace, which is necessary in some applications. It should be understood, however, that the in-process
kernel is not robust to bad user input and will block the main (GUI) thread while executing. Developers
must decide on a case-by-case basis whether this tradeoff is appropriate for their application.
Parallel
IPython.parallel has had some refactoring as well. There are many improvements and fixes, but these are
the major changes:
• Connections have been simplified. All ports and the serialization in use are written to the connection
file, rather than the initial two-stage system.
• Serialization has been rewritten, fixing many bugs and dramatically improving performance serializ-
ing large containers.
• Load-balancing scheduler performance with large numbers of tasks has been dramatically improved.
• There should be fewer (hopefully zero) false-positives for engine failures.
• Increased compatibility with various use cases that produced serialization / argument errors with map,
etc.
• The controller can attempt to resume operation if it has crashed, by passing ipcontroller
--restore.
• Engines can monitor the Hub heartbeat, and shutdown if the Hub disappears for too long.
• add HTCondor support in launchers
QtConsole
Various fixes, including improved performance with lots of text output, and better drag and drop sup-
port. The initial window size of the qtconsole is now configurable via IPythonWidget.width and
IPythonWidget.height.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
We closed a total of 76 issues, 58 pull requests and 18 regular issues; this is the full list (generated with the
script tools/github_stats.py):
Pull Requests (58):
• PR #4188: Allow user_ns trait to be None
• PR #4189: always fire LOCAL_IPS.extend(PUBLIC_IPS)
• PR #4174: various issues in markdown and rst templates
• PR #4178: add missing data_javascript
• PR #4181: nbconvert: Fix, sphinx template not removing new lines from headers
• PR #4043: don’t ‘restore_bytes’ in from_JSON
• PR #4163: Fix for incorrect default encoding on Windows.
• PR #4136: catch javascript errors in any output
• PR #4171: add nbconvert config file when creating profiles
• PR #4125: Basic exercise of ipython [subcommand] -h and help-all
• PR #4085: nbconvert: Fix sphinx preprocessor date format string for Windows
• PR #4159: don’t split .cell and div.cell CSS
• PR #4158: generate choices for --gui configurable from real mapping
• PR #4065: do not include specific css in embedable one
• PR #4092: nbconvert: Fix for unicode html headers, Windows + Python 2.x
• PR #4074: close Client sockets if connection fails
• PR #4064: Store default codemirror mode in only 1 place
• PR #4104: Add way to install MathJax to a particular profile
• PR #4144: help_end transformer shouldn’t pick up ? in multiline string
• PR #4143: update example custom.js
• PR #4142: DOC: unwrap openssl line in public_server doc
• PR #4141: add files with a separate add call in backport_pr
• PR #4137: Restore autorestore option for storemagic
• PR #4098: pass profile-dir instead of profile name to Kernel
• PR #4120: support input in Python 2 kernels
• PR #4088: nbconvert: Fix coalescestreams line with incorrect nesting causing strange behavior
• PR #4060: only strip continuation prompts if regular prompts seen first
• PR #4132: Fixed name error bug in function safe_unicode in module py3compat.
• PR #4121: move test_kernel from IPython.zmq to IPython.kernel
• Anton I. Sipos
• Antony Lee
• Aron Ahmadia
• Benedikt Sauer
• Benjamin Jones
• Benjamin Ragan-Kelley
• Benjie Chen
• Boris de Laage
• Brad Reisfeld
• Bradley M. Froehle
• Brian E. Granger
• Cameron Bates
• Cavendish McKay
• chapmanb
• Chris Beaumont
• Chris Laumann
• Christoph Gohlke
• codebraker
• codespaced
• Corran Webster
• DamianHeard
• Damián Avila
• Dan Kilman
• Dan McDougall
• Danny Staple
• David Hirschfeld
• David P. Sanders
• David Warde-Farley
• David Wolever
• David Wyde
• debjan
• Diane Trout
• dkua
• Dominik Dabrowski
• Donald Curtis
• Dražen Lučanin
• drevicko
• Eric O. LEBIGOT
• Erik M. Bray
• Erik Tollerud
• Eugene Van den Bulke
• Evan Patterson
• Fernando Perez
• Francesco Montesano
• Frank Murphy
• Greg Caporaso
• Guy Haskin Fernald
• guziy
• Hans Meine
• Harry Moreno
• henryiii
• Ivan Djokic
• Jack Feser
• Jake Vanderplas
• jakobgager
• James Booth
• Jan Schulz
• Jason Grout
• Jeff Knisley
• Jens Hedegaard Nielsen
• jeremiahbuddha
• Jerry Fowler
• Jessica B. Hamrick
• Jez Ng
• John Zwinck
• Jonathan Frederic
• Jonathan Taylor
• Joon Ro
• Joseph Lansdowne
• Juergen Hasch
• Julian Taylor
• Jussi Sainio
• Jörgen Stenarson
• kevin
• klonuo
• Konrad Hinsen
• Kyle Kelley
• Lars Solberg
• Lessandro Mariano
• Mark Sienkiewicz at STScI
• Martijn Vermaat
• Martin Spacek
• Matthias Bussonnier
• Maxim Grechkin
• Maximilian Albert
• MercuryRising
• Michael Droettboom
• Michael Shuffett
• Michał Górny
• Mikhail Korobov
• mr.Shu
• Nathan Goldbaum
• ocefpaf
• Ohad Ravid
• Olivier Grisel
• Olivier Verdier
• Owen Healy
• Pankaj Pandey
• Paul Ivanov
• Pawel Jasinski
• Pietro Berkes
• Piti Ongmongkolkul
• Puneeth Chaganti
• Rich Wareham
• Richard Everson
• Rick Lupton
• Rob Young
• Robert Kern
• Robert Marchman
• Robert McGibbon
• Rui Pereira
• Rustam Safin
• Ryan May
• s8weber
• Samuel Ainsworth
• Sean Vig
• Siyu Zhang
• Skylar Saveland
• slojo404
• smithj1
• Stefan Karpinski
• Stefan van der Walt
• Steven Silvester
• Takafumi Arakaki
• Takeshi Kanmae
• tcmulcahy
• teegaar
• Thomas Kluyver
• Thomas Robitaille
• Thomas Spura
• Thomas Weißschuh
• Timothy O’Donnell
• Tom Dimiduk
• ugurthemaster
• urielshaolin
• v923z
• Valentin Haenel
• Victor Zverovich
• 23. Trevor King
• y-p
• Yoav Ram
• Zbigniew J˛edrzejewski-Szmek
• Zoltán Vörös
We closed a total of 1484 issues, 793 pull requests and 691 regular issues; this is the full list (generated with
the script tools/github_stats.py):
Pull Requests (793):
• PR #3958: doc update
• PR #3965: Fix ansi color code for background yellow
• PR #3964: Fix casing of message.
• PR #3942: Pass on install docs
• PR #3962: exclude IPython.lib.kernel in iptest
• PR #3961: Longpath test fix
• PR #3905: Remove references to 0.11 and 0.12 from config/overview.rst
• PR #3951: nbconvert: fixed latex characters not escaped properly in nbconvert
• PR #3949: log fatal error when PDF conversion fails
• PR #3947: nbconvert: Make writer & post-processor aliases case insensitive.
• PR #3938: Recompile css.
• PR #3948: sphinx and PDF tweaks
• PR #3943: nbconvert: Serve post-processor Windows fix
• PR #3934: nbconvert: fix logic of verbose flag in PDF post processor
• PR #2796: P3K: fix cookie parsing under Python 3.x (+ duplicate import is removed)
• PR #2724: In-process kernel support (take 3)
• PR #2687: [WIP] Metaui slideshow
• PR #2788: Chrome frame awareness
• PR #2649: Add version_request/reply messaging protocol
• PR #2753: add %%px --local for local execution
• PR #2783: Prefilter shouldn’t touch execution_count
• PR #2333: UI For Metadata
• PR #2396: create a ipynbv3 json schema and a validator
• PR #2757: check for complete pyside presence before trying to import
• PR #2782: Allow the %run magic with ‘-b’ to specify a file.
• PR #2778: P3K: fix DeprecationWarning under Python 3.x
• PR #2776: remove non-functional View.kill method
• PR #2755: can interactively defined classes
• PR #2774: Removing unused code in the notebook MappingKernelManager.
• PR #2773: Fixed minor typo causing AttributeError to be thrown.
• PR #2609: Add ‘unique’ option to history_request messaging protocol
• PR #2769: Allow shutdown when no engines are registered
• PR #2766: Define __file__ when we %edit a real file.
• PR #2476: allow %edit <variable> to work when interactively defined
• PR #2763: Reset readline delimiters after loading rmagic.
• PR #2460: Better handling of __file__ when running scripts.
• PR #2617: Fix for units argument. Adds a res argument.
• PR #2738: Unicode content crashes the pager (console)
• PR #2749: Tell Travis CI to test on Python 3.3 as well
• PR #2744: Don’t show ‘try %paste’ message while using magics
• PR #2728: shift tab for tooltip
• PR #2741: Add note to %cython Black-Scholes example warning of missing erf.
• PR #2743: BUG: Octavemagic inline plots not working on Windows: Fixed
• PR #2740: Following #2737 this error is now a name error
• PR #2737: Rmagic: error message when moving an non-existant variable from python to R
• PR #2723: diverse fixes for project url
• #3634: nbconvert reveal to pdf conversion ignores styling, prints only a single page.
• #1307: Remove pyreadline workarounds, we now require pyreadline >= 1.7.1
• #3316: find_cmd test failure on Windows
• #3494: input() in notebook doesn’t work in Python 3
• #3427: Deprecate $ as mathjax delimiter
• #3625: Pager does not open from button
• #3149: Miscellaneous small nbconvert feedback
• #3617: 256 color escapes support
• #3609: %pylab inline blows up for single process ipython
• #2934: Publish the Interactive MPI Demo Notebook
• #3614: ansi escapes broken in master (ls –color)
• #3610: If you don’t have markdown, python setup.py install says no pygments
• #3547: %run modules clobber each other
• #3602: import_item fails when one tries to use DottedObjectName instead of a string
• #3563: Duplicate tab completions in the notebook
• #3599: Problems trying to run IPython on python3 without installing...
• #2937: too long completion in notebook
• #3479: Write empty name for the notebooks
• #3505: nbconvert: Failure in specifying user filter
• #1537: think a bit about namespaces
• #3124: Long multiline strings in Notebook
• #3464: run -d message unclear
• #2706: IPython 0.13.1 ignoring $PYTHONSTARTUP
• #3587: LaTeX escaping bug in nbconvert when exporting to HTML
• #3213: Long running notebook died with a coredump
• #3580: Running ipython with pypy on windows
• #3573: custom.js not working
• #3544: IPython.lib test failure on Windows
• #3352: Install Sphinx extensions
• #2971: [notebook]user needs to press ctrl-c twice to stop notebook server should be put into terminal
window
• #2413: ipython3 qtconsole fails to install: ipython 0.13 has no such extra feature ‘qtconsole’
• #3426: Feature request: Save by cell and not by line #: IPython %save magic
• #3412: Non Responsive Kernel: Running a Django development server from an IPython Notebook
• #3408: Save cell toolbar and slide type metadata in notebooks
• #3246: %paste regression with blank lines
• #3404: Weird error with $variable and grep in command line magic (!command)
• #3405: Key auto-completion in dictionaries?
• #3259: Codemirror linenumber css broken
• #3397: Vertical text misalignment in Markdown cells
• #3391: Revert #3358 once fix integrated into CM
• #3360: Error 500 while saving IPython notebook
• #3375: Frequent Safari/Webkit crashes
• #3365: zmq frontend
• #2654: User_expression issues
• #3389: Store history as plain text
• #3388: Ipython parallel: open TCP connection created for each result returned from engine
• #3385: setup.py failure on Python 3
• #3376: Setting __module__ to None breaks pretty printing
• #3374: ipython qtconsole does not display the prompt on OSX
• #3380: simple call to kernel
• #3379: TaskRecord key ‘started’ not set
• #3241: notebook conection time out
• #3334: magic interpreter interpretes non magic commands?
• #3326: python3.3: Type error when launching SGE cluster in IPython notebook
• #3349: pip3 doesn’t run 2to3?
• #3347: Longlist support in ipdb
• #3343: Make pip install / easy_install faster
• #3337: git submodules broke nightly PPA builds
• #3206: Copy/Paste Regression in QtConsole
• #3329: Buggy linewrap in Mac OSX Terminal (Mountain Lion)
• #3327: Qt version check broken
• #3303: parallel tasks never finish under heavy load
• #1381: ‘\’ for equation continuations require an extra ‘’ in markdown cells
• #3178: cell magics do not work with empty lines after #2447
• #3204: Default plot() colors unsuitable for red-green colorblind users
• #1789: :\n/*foo turns into :\n*(foo) in triple-quoted strings.
• #3202: File cell magic fails with blank lines
• #3199: %%cython -a stopped working?
• #2688: obsolete imports in import autocompletion
• #3192: Python2, Unhandled exception, __builtin__.True = False
• #3179: script magic error message loop
• #3009: use XDG_CACHE_HOME for cython objects
• #3059: Bugs in 00_notebook_tour example.
• #3104: Integrate a javascript file manager into the notebook front end
• #3176: Particular equation not rendering (notebook)
• #1133: [notebook] readonly and upload files/UI
• #2975: [notebook] python file and cell toolbar
• #3017: SciPy.weave broken in IPython notebook/ qtconsole
• #3161: paste macro not reading spaces correctly
• #2835: %paste not working on WinXpSP3/ipython-0.13.1.py2-win32-PROPER.exe/python27
• #2628: Make transformers work for lines following decorators
• #2612: Multiline String containing ”:n?foon” confuses interpreter to replace ?foo with
get_ipython().magic(u’pinfo foo’)
• #2539: Request: Enable cell magics inside of .ipy scripts
• #2507: Multiline string does not work (includes ...) with doctest type input in IPython notebook
• #2164: Request: Line breaks in line magic command
• #3106: poor parallel performance with many jobs
• #2438: print inside multiprocessing crashes Ipython kernel
• #3155: Bad md5 hash for package 0.13.2
• #3045: [Notebook] Ipython Kernel does not start if disconnected from internet(/network?)
• #3146: Using celery in python 3.3
• #3145: The notebook viewer is down
• #2385: grep –color not working well with notebook
• #3131: Quickly install from source in a clean virtualenv?
• #3139: Rolling log for ipython
• #2902: ActiveState attempt to build ipython 0.12.1 for python 3.2.2 for Mac OS failed
• #2899: Test failure in IPython.core.tests.test_magic.test_time
• #2890: Test failure when fabric not installed
• #2892: IPython tab completion bug for paths
• #1340: Allow input cells to be collapsed
• #2881: ? command in notebook does not show help in Safari
• #2751: %%timeit should use minutes to format running time in long running cells
• #2879: When importing a module with a wrong name, ipython crashes
• #2862: %%timeit should warn of empty contents
• #2485: History navigation breaks in qtconsole
• #2785: gevent input hook
• #2843: Sliently running code in clipboard (with paste, cpaste and variants)
• #2784: %run -t -N<N> error
• #2732: Test failure with FileLinks class on Windows
• #2860: ipython help notebook -> KeyError: ‘KernelManager’
• #2858: Where is the installed ipython script?
• #2856: Edit code entered from ipython in external editor
• #2722: IPC transport option not taking effect ?
• #2473: Better error messages in ipengine/ipcontroller
• #2836: Cannot send builtin module definitions to IP engines
• #2833: Any reason not to use super() ?
• #2781: Cannot interrupt infinite loops in the notebook
• #2150: clippath_demo.py in matplotlib example does not work with inline backend
• #2634: Numbered list in notebook markdown cell renders with Roman numerals instead of numbers
• #2230: IPython crashing during startup with “AttributeError: ‘NoneType’ object has no attribute
‘rstrip”’
• #2483: nbviewer bug? with multi-file gists
• #2466: mistyping ed -p breaks ed -p
• #2477: Glob expansion tests fail on Windows
• #2622: doc issue: notebooks that ship with Ipython .13 are written for python 2.x
• #2626: Add “Cell -> Run All Keep Going” for notebooks
• #1223: Show last modification date of each notebook
• #2330: qtconsole does not hightlight tab-completion suggestion with custom stylesheet
• #2325: Parsing Tex formula fails in Notebook
• #2324: Parsing Tex formula fails
• #1474: Add argument to run -n for custom namespace
• #2318: C-m n/p don’t work in Markdown cells in the notebook
• #2309: time.time() in ipython notebook producing impossible results
• #2307: schedule tasks on newly arrived engines
• #2313: Allow Notebook HTML/JS to send messages to Python code
• #2304: ipengine throws KeyError: url
• #1878: shell access using ! will not fill class or function scope vars
• #2253: %paste does not retrieve clipboard contents under screen/tmux on OS X
• #1510: Add-on (or Monkey-patch) infrastructure for HTML notebook
• #2273: triple quote and %s at beginning of line with %paste
• #2243: Regression in .embed()
• #2266: SSH passwordless check with OpenSSH checks for the wrong thing
• #2217: Change NewNotebook handler to use 30x redirect
• #2276: config option for disabling history store
• #2239: can’t use parallel.Reference in view.map
• #2272: Sympy piecewise messed up rendering
• #2252: %paste throws an exception with empty clipboard
• #2259: git-mpr is currently broken
• #2247: Variable expansion in shell commands should work in substrings
• #2026: Run ‘fast’ tests only
• #2241: read a list of notebooks on server and bring into browser only notebook
• #2237: please put python and text editor in the web only ipython
• #2053: Improvements to the IPython.display.Image object
• #1456: ERROR: Internal Python error in the inspect module.
• #2221: Avoid importing from IPython.parallel in core
• #2213: Can’t trigger startup code in Engines
• #1464: Strange behavior for backspace with lines ending with more than 4 spaces in notebook
• #2187: NaN in object_info_reply JSON causes parse error
• #214: system command requiring administrative privileges
• #1513: Add expand/collapse support for long output elements like stdout and tracebacks
• #2087: error when starting ipython
• #2103: Ability to run notebook file from commandline
• #2082: Qt Console output spacing
• #2083: Test failures with Python 3.2 and PYTHONWARNINGS=”d”
• #2094: about inline
• #2077: Starting IPython3 on the terminal
• #1760: easy_install ipython fails on py3.2-win32
• #2075: Local Mathjax install causes iptest3 error under python3
• #2057: setup fails for python3 with LANG=C
• #2070: shebang on Windows
• #2054: sys_info missing git hash in sdists
• #2059: duplicate and modified files in documentation
• #2056: except-shadows-builtin osm.py:687
• #2058: hyphen-used-as-minus-sign in manpages
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
0.13 Series
Release 0.13
IPython 0.13 contains several major new features, as well as a large amount of bug and regression fixes. The
previous version (0.12) was released on December 19 2011, and in this development cycle we had:
• ~6 months of work.
• 373 pull requests merged.
• 742 issues closed (non-pull requests).
• contributions from 62 authors.
• 1760 commits.
• a diff of 114226 lines.
The amount of work included in this release is so large, that we can only cover here the main highlights;
please see our detailed release statistics for links to every issue and pull request closed on GitHub as well
as a full list of individual contributors.
The IPython Notebook, which has proven since its release to be wildly popular, has seen a massive amount of
work in this release cycle, leading to a significantly improved user experience as well as many new features.
The first user-visible change is a reorganization of the user interface; the left panel has been re-
moved and was replaced by a real menu system and a toolbar with icons. Both the tool-
bar and the header above the menu can be collapsed to leave an unobstructed working area:
Note: The auto-folding of long outputs is disabled in Firefox due to bugs in its scrolling behavior. See PR
#2047 for details.
Uploading notebooks to the dashboard is now easier: in addition to drag and drop (which
can be finicky sometimes), you can now click on the upload text and use a regular file di-
alog box to select notebooks to upload. Furthermore, the notebook dashboard now auto-
refreshes its contents and offers buttons to shut down any running kernels (PR #1739):
Cluster management
The notebook dashboard can now also start and stop clusters, thanks to a new tab in the dashboard user
The notebooks saved now use version 3 of our format, which supports heading levels as well as the concept
of ‘raw’ text cells that are not rendered as Markdown. These will be useful with converters we are develop-
ing, to pass raw markup (say LaTeX). That conversion code is still under heavy development and not quite
ready for prime time, but we welcome help on this front so that we can merge it for full production use as
soon as possible.
Note: v3 notebooks can not be read by older versions of IPython, but we provide a simple script that you
can use in case you need to export a v3 notebook to share with a v2 user.
JavaScript refactoring
All the client-side JavaScript has been decoupled to ease reuse of parts of the machinery without having to
build a full-blown notebook. This will make it much easier to communicate with an IPython kernel from
existing web pages and to integrate single cells into other sites, without loading the full notebook document-
like UI. PR #1711.
This refactoring also enables the possibility of writing dynamic javascript widgets that are returned from
Python code and that present an interactive view to the user, with callbacks in Javascript executing calls to
the Kernel. This will enable many interactive elements to be added by users in notebooks.
An example of this capability has been provided as a proof of concept in examples/widgets that lets
you directly communicate with one or more parallel engines, acting as a mini-console for parallel debugging
and introspection.
Improved tooltips
The object tooltips have gained some new functionality. By pressing tab several times, you can expand
them to see more of a docstring, keep them visible as you fill in a function’s parameters, or transfer
the information to the pager at the bottom of the screen. For the details, look at the example notebook
01_notebook_introduction.ipynb.
These are some other notable small improvements to the notebook, in addition to many bug fixes and minor
changes to add polish and robustness throughout:
• The notebook pager (the area at the bottom) is now resizeable by dragging its divider handle, a feature
that had been requested many times by just about anyone who had used the notebook system. PR
#1705.
• It is now possible to open notebooks directly from the command line; for example: ipython
notebook path/ will automatically set path/ as the notebook directory, and ipython
notebook path/foo.ipynb will further start with the foo.ipynb notebook opened. PR
#1686.
• If a notebook directory is specified with --notebook-dir (or with the corresponding configuration
flag NotebookManager.notebook_dir), all kernels start in this directory.
• Fix codemirror clearing of cells with Ctrl-Z; PR #1965.
• Text (markdown) cells now line wrap correctly in the notebook, making them much easier to edit PR
#1330.
• PNG and JPEG figures returned from plots can be interactively resized in the notebook, by dragging
them from their lower left corner. PR #1832.
• Clear In [] prompt numbers on “Clear All Output”. For more version-control-friendly .ipynb
files, we now strip all prompt numbers when doing a “Clear all output”. This reduces the amount
of noise in commit-to-commit diffs that would otherwise show the (highly variable) prompt number
changes. PR #1621.
• The notebook server now requires two consecutive Ctrl-C within 5 seconds (or an interactive confir-
mation) to terminate operation. This makes it less likely that you will accidentally kill a long-running
server by typing Ctrl-C in the wrong terminal. PR #1609.
• Using Ctrl-S (or Cmd-S on a Mac) actually saves the notebook rather than providing the fairly
useless browser html save dialog. PR #1334.
• Allow accessing local files from the notebook (in urls), by serving any local file as the url files/
<relativepath>. This makes it possible to, for example, embed local images in a notebook. PR
#1211.
Cell magics
We have completely refactored the magic system, finally moving the magic objects to standalone, indepen-
dent objects instead of being the mixin class we’d had since the beginning of IPython (PR #1732). Now,
a separate base class is provided in IPython.core.magic.Magics that users can subclass to create
their own magics. Decorators are also provided to create magics from simple functions without the need for
object orientation. Please see the Magic command system docs for further details.
All builtin magics now exist in a few subclasses that group together related functionality, and the new
IPython.core.magics package has been created to organize this into smaller files.
This cleanup was the last major piece of deep refactoring needed from the original 2001 codebase.
We have also introduced a new type of magic function, prefixed with %% instead of %, which operates at the
whole-cell level. A cell magic receives two arguments: the line it is called on (like a line magic) and the
body of the cell below it.
Cell magics are most natural in the notebook, but they also work in the terminal and qt console, with the
usual approach of using a blank line to signal cell termination.
For example, to time the execution of several statements:
%%timeit x = 0 # setup
for i in range(100000):
x += i**2
This is particularly useful to integrate code in another language, and cell magics already exist for shell
scripts, Cython, R and Octave. Using %%script /usr/bin/foo, you can run a cell in any interpreter
that accepts code via stdin.
Another handy cell magic makes it easy to write short text files: %%file ~/save/to/here.txt.
The following cell magics are now included by default; all those that use special interpreters (Perl, Ruby,
bash, etc.) assume you have the requisite interpreter installed:
• %%!: run cell body with the underlying OS shell; this is similar to prefixing every line in the cell with
!.
In addition, we have
also a number of extensions that provide specialized magics. These typically require additional software to
run and must be manually loaded via %load_ext <extension name>, but are extremely useful. The
following extensions are provided:
Cython magics (extension cythonmagic) This extension provides magics to automatically build and com-
pile Python extension modules using the Cython language. You must install Cython separately, as
well as a C compiler, for this to work. The examples directory in the source distribution ships with a
full notebook demonstrating these capabilities:
Octave magics (extension octavemagic) This extension provides several magics that support calling
code written in the Octave language for numerical computing. You can execute single-lines or whole
blocks of Octave code, capture both output and figures inline (just like matplotlib plots), and have
variables automatically converted between the two languages. To use this extension, you must have
Octave installed as well as the oct2py package. The examples directory in the source distribution
ships with a full notebook demonstrating these capabilities:
R magics (extension rmagic) This extension provides several magics that support calling code written in
the R language for statistical data analysis. You can execute single-lines or whole blocks of R code,
capture both output and figures inline (just like matplotlib plots), and have variables automatically
converted between the two languages. To use this extension, you must have R installed as well as the
rpy2 package that bridges Python and R. The examples directory in the source distribution ships with
a full notebook demonstrating these capabilities:
Useful tab-completion based on live inspection of objects is one of the most popular features of IPython.
To make this process even more user-friendly, the completers of both the Qt console and the Notebook have
been reworked.
The Qt console comes with a new ncurses-like tab completer, activated by default, which lets you cycle
through the available completions by pressing tab, or select a completion with the arrow keys (PR #1851).
In the notebook, completions are now sourced both from object introspection and analysis of surrounding
code, so limited completions can be offered for variables defined in the current cell, or while the kernel is
busy (PR #1711).
Fig. 2.2: The new improved Qt console’s ncurses-like completer allows to easily navigate thought long list
of completions.
We have implemented a new configurable flag to control tab completion on modules that provide the
__all__ attribute:
IPCompleter.limit_to__all__= Boolean
This instructs the completer to honor __all__ for the completion. Specifically, when completing on
object.<tab>, if True: only those names in obj.__all__ will be included. When False [default]:
the __all__ attribute is ignored. PR #1529.
The Qt console continues to receive improvements and refinements, despite the fact that it is by now a fairly
mature and robust component. Lots of small polish has gone into it, here are a few highlights:
• A number of changes were made to the underlying code for easier integration into other projects such
as Spyder (PR #2007, PR #2024).
• Improved menus with a new Magic menu that is organized by magic groups (this was made possible
by the reorganization of the magic system internals). PR #1782.
• Allow for restarting kernels without clearing the qtconsole, while leaving a visible indication that the
kernel has restarted. PR #1681.
• Allow the native display of jpeg images in the qtconsole. PR #1643.
Parallel
The parallel tools have been improved and fine-tuned on multiple fronts. Now, the creation of an IPython.
parallel.Client object automatically activates a line and cell magic function px that sends its code
to all the engines. Further magics can be easily created with the Client.activate() method, to con-
veniently execute code on any subset of engines. PR #1893.
The %%px cell magic can also be given an optional targets argument, as well as a --out argument for
storing its output.
A new magic has also been added, %pxconfig, that lets you configure various defaults of the parallel
magics. As usual, type %pxconfig? for details.
The exception reporting in parallel contexts has been improved to be easier to read. Now,
IPython directly reports the remote exceptions without showing any of the internal execution parts:
Set TaskScheduler.hwm default to 1 instead of 0. 1 has more predictable/intuitive behavior, if often slower,
and thus a more logical default. Users whose workloads require maximum throughput and are largely
homogeneous in time per task can make the optimization themselves, but now the behavior will be less
surprising to new users. PR #1294.
Kernel/Engine unification
This is mostly work ‘under the hood’, but it is actually a major achievement for the project that has deep
implications in the long term: at last, we have unified the main object that executes as the user’s interactive
shell (which we refer to as the IPython kernel) with the objects that run in all the worker nodes of the parallel
computing facilities (the IPython engines). Ever since the first implementation of IPython’s parallel code
back in 2006, we had wanted to have these two roles be played by the same machinery, but a number of
technical reasons had prevented that from being true.
In this release we have now merged them, and this has a number of important consequences:
• It is now possible to connect any of our clients (qtconsole or terminal console) to any individual
parallel engine, with the exact behavior of working at a ‘regular’ IPython console/qtconsole. This
makes debugging, plotting, etc. in parallel scenarios vastly easier.
• Parallel engines can always execute arbitrary ‘IPython code’, that is, code that has magics, shell
extensions, etc. In combination with the %%px magics, it is thus extremely natural for example to
send to all engines a block of Cython or R code to be executed via the new Cython and R magics. For
example, this snippet would send the R block to all active engines in a cluster:
%%px
%%R
... R code goes here
• It is possible to embed not only an interactive shell with the IPython.embed() call as always, but
now you can also embed a kernel with IPython.embed_kernel(). Embedding an IPython ker-
nel in an application is useful when you want to use IPython.embed() but don’t have a terminal
attached on stdin and stdout.
• The new IPython.parallel.bind_kernel() allows you to promote Engines to listening
Kernels, and connect QtConsoles to an Engine and debug it directly.
In addition, having a single core object through our entire architecture also makes the project conceptually
cleaner, easier to maintain and more robust. This took a lot of work to get in place, but we are thrilled to
have this major piece of architecture finally where we’d always wanted it to be.
We have begun organizing our API for easier public use, with an eye towards an official IPython 1.0 re-
lease which will firmly maintain this API compatible for its entire lifecycle. There is now an IPython.
display module that aggregates all display routines, and the IPython.config namespace has all
public configuration tools. We will continue improving our public API layout so that users only need to
import names one level deeper than the main IPython package to access all public namespaces.
The directory docs/resources in the source distribution contains SVG and PNG versions of our file
icons, as well as an Info.plist.example file with instructions to install them on Mac OSX. This is a
first draft of our icons, and we encourage contributions from users with graphic talent to improve them in
the future:
Add locate entry points; these would be useful for quickly locating IPython directories and profiles from
other (non-Python) applications. PR #1762.
Examples:
• The IPYTHON_DIR environment variable, introduced in the Great Reorganization of 0.11 and ex-
isting only in versions 0.11-0.13, has been deprecated. As described in PR #1167, the complexity
and confusion of migrating to this variable is not worth the aesthetic improvement. Please use the
historical IPYTHONDIR environment variable instead.
• The default value of interactivity passed from run_cell() to run_ast_nodes() is now config-
urable.
• New %alias_magic function to conveniently create aliases of existing magics, if you prefer to
have shorter names for personal use.
• We ship unminified versions of the JavaScript libraries we use, to better comply with Debian’s pack-
aging policies.
• Simplify the information presented by obj?/obj?? to eliminate a few redundant fields when pos-
sible. PR #2038.
• Improved continuous integration for IPython. We now have automated test runs on Shining Panda and
Travis-CI, as well as Tox support.
• The vim-ipython functionality (externally developed) has been updated to the latest version.
• The %save magic now has a -f flag to force overwriting, which makes it much more usable in the
notebook where it is not possible to reply to interactive questions from the kernel. PR #1937.
• Use dvipng to format sympy.Matrix, enabling display of matrices in the Qt console with the sympy
printing extension. PR #1861.
• Our messaging protocol now has a reasonable test suite, helping ensure that we don’t accidentally
deviate from the spec and possibly break third-party applications that may have been using it. We
encourage users to contribute more stringent tests to this part of the test suite. PR #1627.
• Use LaTeX to display, on output, various built-in types with the SymPy printing extension. PR #1399.
• Add Gtk3 event loop integration and example. PR #1588.
• clear_output improvements, which allow things like progress bars and other simple animations
to work well in the notebook (PR #1563):
– clear_output() clears the line, even in terminal IPython, the QtConsole and plain Python
as well, by printing r to streams.
– clear_output() avoids the flicker in the notebook by adding a delay, and firing immediately
upon the next actual display message.
– display_javascript hides its output_area element, so using display to run a bunch
of javascript doesn’t result in ever-growing vertical space.
• Add simple support for running inside a virtualenv. While this doesn’t supplant proper installation (as
users should do), it helps ad-hoc calling of IPython from inside a virtualenv. PR #1388.
In this cycle, we have closed over 740 issues, but a few major ones merit special mention:
• The %pastebin magic has been updated to point to gist.github.com, since unfortunately http://paste.
pocoo.org has closed down. We also added a -d flag for the user to provide a gist description string.
PR #1670.
• Fix %paste that would reject certain valid inputs. PR #1258.
• Fix sending and receiving of Numpy structured arrays (those with composite dtypes, often used as
recarrays). PR #2034.
• Reconnect when the websocket connection closes unexpectedly. PR #1577.
• Fix truncated representation of objects in the debugger by showing at least 80 characters’ worth of
information. PR #1793.
• Fix logger to be Unicode-aware: logging could crash ipython if there was unicode in the input. PR
#1792.
• Fix images missing from XML/SVG export in the Qt console. PR #1449.
• Fix deepreload on Python 3. PR #1625, as well as having a much cleaner and more robust implemen-
tation of deepreload in general. PR #1457.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
• André Matos
• Aron Ahmadia
• Ben Edwards
• Benjamin Ragan-Kelley
• Bradley M. Froehle
• Brandon Parsons
• Brian E. Granger
• Carlos Cordoba
• David Hirschfeld
• David Zderic
• Ernie French
• Fernando Perez
• Ian Murray
• Jason Grout
• Jens H Nielsen
• Jez Ng
• Jonathan March
• Jonathan Taylor
• Julian Taylor
• Jörgen Stenarson
• Kent Inverarity
• Marc Abramowitz
• Mark Wiebe
• Matthew Brett
• Matthias BUSSONNIER
• Michael Droettboom
• Mike Hansen
• Nathan Rice
• Pankaj Pandey
• Paul
• Paul Ivanov
• Piotr Zolnierczuk
• Piti Ongmongkolkul
• Puneeth Chaganti
• Robert Kern
• Ross Jones
• Roy Hyunjin Han
• Scott Tsai
• Skipper Seabold
• Stefan van der Walt
• Steven Johnson
• Takafumi Arakaki
• Ted Wright
• Thomas Hisch
• Thomas Kluyver
• Thomas Spura
• Thomi Richards
• Tim Couper
• Timo Paulssen
• Toby Gilham
• Tony S Yu
• 23. Trevor King
• Walter Doerwald
• anatoly techtonik
• fawce
• mcelrath
• wilsaj
We closed a total of 1115 issues, 373 pull requests and 742 regular issues; this is the full list (generated with
the script tools/github_stats.py):
Pull Requests (373):
• PR #1943: add screenshot and link into releasenotes
• PR #1954: update some example notebooks
• PR #2048: move _encode_binary to jsonutil.encode_images
• PR #2050: only add quotes around xunit-file on Windows
• PR #1606: Share code for %pycat and %loadpy, make %pycat aware of URLs
• PR #1757: Open IPython notebook hyperlinks in a new window using target=_blank
• PR #1754: Fix typo enconters->encounters
• PR #1753: Clear window title when kernel is restarted
• PR #1449: Fix for bug #735 : Images missing from XML/SVG export
• PR #1743: Tooltip completer js refactor
• PR #1681: add qt config option to clear_on_kernel_restart
• PR #1733: Tooltip completer js refactor
• PR #1727: terminate kernel after embed_kernel tests
• PR #1737: add HistoryManager to ipapp class list
• PR #1686: ENH: Open a notebook from the command line
• PR #1709: fixes #1708, failing test in arg_split on windows
• PR #1718: Use CRegExp trait for regular expressions.
• PR #1729: Catch failure in repr() for %whos
• PR #1726: use eval for command-line args instead of exec
• PR #1724: fix scatter/gather with targets=’all’
• PR #1725: add –no-ff to git pull in test_pr
• PR #1721: Tooltip completer js refactor
• PR #1657: Add wait optional argument to hooks.editor
• PR #1717: Define generic sys.ps{1,2,3}, for use by scripts.
• PR #1691: Finish PR #1446
• PR #1710: update MathJax CDN url for https
• PR #1713: Make autocall regexp’s configurable.
• PR #1703: Allow TryNext to have an error message without it affecting the command chain
• PR #1714: minor adjustments to test_pr
• PR #1704: ensure all needed qt parts can be imported before settling for one
• PR #1706: Mark test_push_numpy_nocopy as a known failure for Python 3
• PR #1698: fix tooltip on token with number
• PR #1245: pythonw py3k fixes for issue #1226
• PR #1685: Add script to test pull request
• PR #1693: deprecate IPYTHON_DIR in favor of IPYTHONDIR
• PR #1695: Avoid deprecated warnings from ipython-qtconsole.desktop.
• #1399: Use LaTeX to print various built-in types with the SymPy printing extension
• #1597: re-enter kernel.eventloop after catching SIGINT
• #1490: rename plaintext cell -> raw cell
• #1487: %notebook fails in qtconsole
• #1545: trailing newline not preserved in splitline ipynb
• #1480: Fix %notebook magic, etc. nbformat unicode tests and fixes
• #1588: Gtk3 integration with ipython works.
• #1595: Examples syntax (avoid errors installing on Python 3)
• #1526: Find encoding for Python files
• #1594: Fix writing git commit ID to a file on build with Python 3
• #1556: shallow-copy DictDB query results
• #1499: various pyflakes issues
• #1502: small changes in response to pyflakes pass
• #1445: Don’t build sphinx docs for sdists
• #1484: unhide .git_commit_info.ini
• #1538: store git commit hash in utils._sysinfo instead of hidden data file
• #1546: attempt to suppress exceptions in channel threads at shutdown
• #1524: unhide git_commit_info.ini
• #1559: update tools/github_stats.py to use GitHub API v3
• #1563: clear_output improvements
• #1558: Ipython testing documentation still mentions twisted and trial
• #1560: remove obsolete discussion of Twisted/trial from testing docs
• #1561: Qtconsole - nonstandard a and b
• #1569: BUG: qtconsole – non-standard handling of a and b. [Fixes #1561]
• #1574: BUG: Ctrl+C crashes wx pylab kernel in qtconsole
• #1573: BUG: Ctrl+C crashes wx pylab kernel in qtconsole.
• #1590: ‘iPython3 qtconsole’ doesn’t work in Windows 7
• #602: User test the html notebook
• #613: Implement Namespace panel section
• #879: How to handle Javascript output in the notebook
• #1255: figure.show() raises an error with the inline backend
• #1467: Document or bundle a git-integrated facility for stripping VCS-unfriendly binary data
• #1250: Wijmoize
• #1244: can not imput chinese word “” , exit right now
• #1194: Adding Opera 11 as a compatible browser for ipython notebook
• #1198: Kernel Has Died error in Notebook
• #1211: serve local files in notebook-dir
• #1224: edit text cells on double-click instead of single-click
• #1187: misc notebook: connection file cleanup, first heartbeat, startup flush
• #1207: fix loadpy duplicating newlines
• #1060: Always save the .py file to disk next to the .ipynb
• #1066: execute cell in place should preserve the current insertion-point in the notebook
• #1141: “In” numbers are not invalidated when restarting kernel
• #1231: pip on OSX tries to install files in /System directory.
• #1129: Unified setup.py
• #1199: Reduce IPython.external.*
• #1219: Make all the static files path absolute.
• #1218: Added -q option to %prun for suppression of the output, along with editing the dochelp string.
• #1217: Added -q option to %prun for suppression of the output, along with editing the dochelp string
• #1216: Pdb tab completion does not work in QtConsole
• #1197: Interactive shell trying to: from ... import history
• #1175: core.completer: Clean up excessive and unused code.
• #1208: should dv.sync_import print failed imports ?
• #1186: payloadpage.py not used by qtconsole
• #1204: double newline from %loadpy in python notebook (at least on mac)
• #1192: Invalid JSON data
• #1196: docs: looks like a file path might have been accidentally pasted in the middle of a word
• #1189: Right justify of ‘in’ prompt in variable prompt size configurations
• #1185: ipython console not work proper with stdout...
• #1191: profile/startup files not executed with “notebook”
• #1190: Fix link to Chris Fonnesbeck blog post about 0.11 highlights.
• #1174: Remove %install_default_config and %install_profiles
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
0.12 Series
Release 0.12.1
IPython 0.12.1 is a bugfix release of 0.12, pulling only bugfixes and minor cleanup from 0.13, timed for the
Ubuntu 12.04 LTS release.
See the list of fixed issues for specific backported issues.
Release 0.12
IPython 0.12 contains several major new features, as well as a large amount of bug and regression fixes.
The 0.11 release brought with it a lot of new functionality and major refactorings of the codebase; by and
large this has proven to be a success as the number of contributions to the project has increased dramatically,
proving that the code is now much more approachable. But in the refactoring inevitably some bugs were
introduced, and we have also squashed many of those as well as recovered some functionality that had been
temporarily disabled due to the API changes.
The following major new features appear in this version.
A powerful new interface puts IPython in your browser. You can start it with the command ipython
notebook:
Fig. 2.3: The new IPython notebook showing text, mathematical expressions in LaTeX, code, results and
embedded figures created with Matplotlib.
This new interface maintains all the features of IPython you are used to, as it is a new client that communi-
cates with the same IPython kernels used by the terminal and Qt console. But the web notebook provides
for a different workflow where you can integrate, along with code execution, also text, mathematical expres-
sions, graphics, video, and virtually any content that a modern browser is capable of displaying.
You can save your work sessions as documents that retain all these elements and which can be version
controlled, emailed to colleagues or saved as HTML or PDF files for printing or publishing statically on the
web. The internal storage format is a JSON file that can be easily manipulated for manual exporting to other
formats.
This Notebook is a major milestone for IPython, as for years we have tried to build this kind of system. We
were inspired originally by the excellent implementation in Mathematica, we made a number of attempts
using older technologies in earlier Summer of Code projects in 2005 (both students and Robert Kern devel-
oped early prototypes), and in recent years we have seen the excellent implementation offered by the Sage
<http://sagemath.org> system. But we continued to work on something that would be consistent
with the rest of IPython’s design, and it is clear now that the effort was worth it: based on the ZeroMQ
communications architecture introduced in version 0.11, the notebook can now retain 100% of the features
of the real IPython. But it can also provide the rich media support and high quality Javascript libraries that
were not available in browsers even one or two years ago (such as high-quality mathematical rendering or
built-in video).
The notebook has too many useful and important features to describe in these release notes; our docu-
mentation now contains a directory called examples/notebooks with several notebooks that illustrate
various aspects of the system. You should start by reading those named 00_notebook_tour.ipynb
and 01_notebook_introduction.ipynb first, and then can proceed to read the others in any order
you want.
To start the notebook server, go to a directory containing the notebooks you want to open (or where you
want to create new ones) and type:
ipython notebook
and just like the Qt console, you can start the notebook server with pylab support by using:
for plotting support with automatically inlined figures. Note that it is now possible also to activate pylab
support at runtime via %pylab, so you do not need to make this decision when starting the server.
See the Notebook docs for technical details.
Based on the same architecture as the notebook and the Qt console, we also have now a terminal-based
console that can connect to an external IPython kernel (the same kernels used by the Qt console or the
notebook, in fact). While this client behaves almost identically to the usual IPython terminal application,
this capability can be very useful to attach an interactive console to an existing kernel that was started
externally. It lets you use the interactive %debug facilities in a notebook, for example (the web browser
can’t interact directly with the debugger) or debug a third-party code where you may have embedded an
IPython kernel.
This is also something that we have wanted for a long time, and which is a culmination (as a team effort) of
the work started last year during the 2010 Google Summer of Code project.
Tabbed QtConsole
The QtConsole now supports starting multiple kernels in tabs, and has a menubar, so it looks and behaves
more like a real application. Keyboard enthusiasts can disable the menubar with ctrl-shift-M (PR #887).
Fig. 2.4: The improved Qt console for IPython, now with tabs to control multiple kernels and full menu
support.
IPython can now be installed from a single codebase on Python 2 and Python 3. The installation process for
Python 3 automatically runs 2to3. The same ‘default’ profile is now used for Python 2 and 3 (the previous
version had a separate ‘python3’ profile).
Standalone Kernel
The ipython kernel subcommand has been added, to allow starting a standalone kernel, that can be
used with various frontends. You can then later connect a Qt console or a terminal console to this kernel by
typing e.g.:
if it’s the only one running, or by passing explicitly the connection parameters (printed by the kernel at
startup).
PyPy support
The terminal interface to IPython now runs under PyPy. We will continue to monitor PyPy’s progress, and
hopefully before long at least we’ll be able to also run the notebook. The Qt console may take longer, as Qt
is a very complex set of bindings to a huge C++ library, and that is currently the area where PyPy still lags
most behind. But for everyday interactive use at the terminal, with this release and PyPy 1.7, things seem to
work quite well from our admittedly limited testing.
• SSH Tunnels: In 0.11, the IPython.parallel Client could tunnel its connections to the Con-
troller via ssh. Now, the QtConsole supports ssh tunneling, as do parallel engines.
• relaxed command-line parsing: 0.11 was released with overly-strict command-line parsing, pre-
venting the ability to specify arguments with spaces, e.g. ipython --pylab qt or ipython
-c "print 'hi'". This has been fixed, by using argparse. The new parsing is a strict superset of
0.11, so any commands in 0.11 should still work in 0.12.
• HistoryAccessor: The HistoryManager class for interacting with your IPython SQLite history
database has been split, adding a parent HistoryAccessor class, so that users can write code to
access and search their IPython history without being in an IPython session (PR #824).
• kernel %gui and %pylab: The %gui and %pylab magics have been restored to the IPython kernel
(e.g. in the qtconsole or notebook). This allows activation of pylab-mode, or eventloop integration
after starting the kernel, which was unavailable in 0.11. Unlike in the terminal, this can be set only
once, and cannot be changed.
• %config: A new %config magic has been added, giving easy access to the IPython configuration
system at runtime (PR #923).
• Multiline History: Multiline readline history has been restored to the Terminal frontend by default
(PR #838).
• %store: The %store magic from earlier versions has been updated and re-enabled (storemagic;
PR #1029). To autorestore stored variables on startup, specify c.StoreMagic.autorestore =
True in ipython_config.py.
In this cycle, we have closed over 500 issues, but a few major ones merit special mention:
• Simple configuration errors should no longer crash IPython. In 0.11, errors in config files, as well as
invalid trait values, could crash IPython. Now, such errors are reported, and help is displayed.
• Certain SyntaxErrors no longer crash IPython (e.g. just typing keywords, such as return, break,
etc.). See #704.
• IPython path utils, such as get_ipython_dir() now check for write permissions, so IPython
should function on systems where the default path resolution might point to a read-only location, such
as HOMESHARE on Windows (#669).
• raw_input() now works in the kernel when multiple frontends are in use. The request will be sent
to the frontend that made the request, and an exception is raised if that frontend does not support stdin
requests (e.g. the notebook) (#673).
• zmq version detection no longer uses simple lexicographical comparison to check minimum version,
which prevents 0.11 from working with pyzmq-2.1.10 (PR #758).
• A bug in PySide < 1.0.7 caused crashes on OSX when tooltips were shown (#711). these tooltips are
now disabled on old PySide (PR #963).
• IPython no longer crashes when started on recent versions of Python 3 in Windows (#737).
• Instances of classes defined interactively can now be pickled (#29; PR #648). Note that pickling saves
a reference to the class definition, so unpickling the instances will only work where the class has been
defined.
• IPython connection information is no longer specified via ip/port directly, rather via json connection
files. These files are stored in the security directory, and enable us to turn on HMAC message authen-
tication by default, significantly improving the security of kernels. Various utility functions have been
added to IPython.lib.kernel, for easier connecting to existing kernels.
• KernelManager now has one ip, and several port traits, rather than several ip/port pair _addr
traits. This better matches the rest of the code, where the ip cannot not be set separately for each
channel.
• Custom prompts are now configured using a new class, PromptManager, which has traits
for in_template, in2_template (the ...: continuation prompt), out_template and
rewrite_template. This uses Python’s string formatting system, so you can use {time} and
{cwd}, although we have preserved the abbreviations from previous versions, e.g. \# (prompt num-
ber) and \w (working directory). For the list of available fields, refer to the source of IPython/
core/prompts.py.
• The class inheritance of the Launchers in IPython.parallel.apps.launcher used by ip-
cluster has changed, so that trait names are more consistent across batch systems. This may require a
few renames in your config files, if you customized the command-line args for launching controllers
and engines. The configurable names have also been changed to be clearer that they point to class
names, and can now be specified by name only, rather than requiring the full import path of each
class, e.g.:
IPClusterEngines.engine_launcher = 'IPython.parallel.apps.launcher.
˓→MPIExecEngineSetLauncher'
IPClusterStart.controller_launcher = 'IPython.parallel.apps.launcher.
˓→SSHControllerLauncher'
IPClusterEngines.engine_launcher_class = 'MPI'
IPClusterStart.controller_launcher_class = 'SSH'
The full path will still work, and is necessary for using custom launchers not in IPython’s launcher
module.
Further, MPIExec launcher names are now prefixed with just MPI, to better match other batch launch-
ers, and be generally more intuitive. The MPIExec names are deprecated, but continue to work.
• For embedding a shell, note that the parameters user_global_ns and global_ns have been
deprectated in favour of user_module and module respsectively. The new parameters expect a
module-like object, rather than a namespace dict. The old parameters remain for backwards compati-
bility, although user_global_ns is now ignored. The user_ns parameter works the same way
as before, and calling embed() with no arguments still works as before.
The previous version (IPython 0.11) was released on July 31 2011, so this release cycle was roughly 4 1/2
months long, we closed a total of 515 issues, 257 pull requests and 258 regular issues (a detailed list is
available).
Many users and developers contributed code, features, bug reports and ideas to this release. Please do not
hesitate in contacting us if we’ve failed to acknowledge your contribution here. In particular, for this release
we have had commits from the following 45 contributors, a mix of new and regular names (in alphabetical
order by first name):
• Alcides <alcides-at-do-not-span-me.com>
• Ben Edwards <bedwards-at-cs.unm.edu>
• Benjamin Ragan-Kelley <benjaminrk-at-gmail.com>
• Benjamin Thyreau <benjamin.thyreau-at-gmail.com>
Note: This list was generated with the output of git log rel-0.11..HEAD --format='* %aN
<%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u after some cleanup. If you
should be on this list, please add yourself.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
GitHub stats for bugfix release 0.12.1 (12/28/2011-04/16/2012), backporting pull requests from 0.13.
We closed a total of 71 issues: 44 pull requests and 27 issues; this is the full list (generated with the script
tools/github_stats.py).
This list is automatically generated, and may be incomplete:
Pull Requests (44):
• PR #1175: core.completer: Clean up excessive and unused code.
• PR #1187: misc notebook: connection file cleanup, first heartbeat, startup flush
• PR #1190: Fix link to Chris Fonnesbeck blog post about 0.11 highlights.
• PR #1196: docs: looks like a file path might have been accidentally pasted in the middle of a word
• PR #1206: don’t preserve fixConsole output in json
• PR #1207: fix loadpy duplicating newlines
• PR #1213: BUG: Minor typo in history_console_widget.py
• PR #1218: Added -q option to %prun for suppression of the output, along with editing the dochelp
string.
• PR #1222: allow Reference as callable in map/apply
• PR #1229: Fix display of SyntaxError in Python 3
• PR #1246: Skip tests that require X, when importing pylab results in RuntimeError.
• PR #1253: set auto_create flag for notebook apps
• PR #1257: use self.kernel_manager_class in qtconsoleapp
• PR #1262: Heartbeat no longer shares the app’s Context
• PR #1283: HeartMonitor.period should be an Integer
• PR #1284: a fix for GH 1269
• PR #1289: Make autoreload extension work on Python 3.
• PR #1306: Fix %prun input parsing for escaped characters (closes #1302)
• PR #1312: minor heartbeat tweaks
• PR #1318: make Ctrl-D in qtconsole act same as in terminal (ready to merge)
• PR #1341: Don’t attempt to tokenize binary files for tracebacks
• PR #1353: Save notebook as script using unicode file handle.
• PR #1363: Fix some minor color/style config issues in the qtconsole
• PR #1364: avoid jsonlib returning Decimal
• PR #1369: load header with engine id when engine dies in TaskScheduler
• PR #1370: allow draft76 websockets (Safari)
• PR #1374: remove calls to meaningless ZMQStream.on_err
• PR #1377: Saving non-ascii history
• PR #1396: Fix for %tb magic.
• PR #1402: fix symlinked /home issue for FreeBSD
• PR #1413: get_home_dir expands symlinks, adjust test accordingly
• PR #1414: ignore errors in shell.var_expand
• PR #1430: Fix for tornado check for tornado < 1.1.0
• PR #1445: Don’t build sphinx docs for sdists
• PR #1463: Fix completion when importing modules in the cwd.
• PR #1477: fix dangling buffer in IPython.parallel.util
• PR #1495: BUG: Fix pretty-printing for overzealous objects
• PR #1496: BUG: LBYL when clearing the output history on shutdown.
• #1421: ipython32 %run -d breaks with NameError name ‘execfile’ is not defined
• #1484: unhide .git_commit_info.ini
In this cycle, from August 1 to December 28 2011, we closed a total of 515 issues, 257 pull requests and
258 regular issues; this is the full list (generated with the script tools/github_stats.py).
Pull requests (257):
• 1174: Remove %install_default_config and %install_profiles
• 1178: Correct string type casting in pinfo.
• 1096: Show class init and call tooltips in notebook
• 1176: Modifications to profile list
• 1173: don’t load gui/pylab in console frontend
• 1168: Add –script flag as shorthand for notebook save_script option.
• 1165: encode image_tag as utf8 in [x]html export
• 1161: Allow %loadpy to load remote URLs that don’t end in .py
• 1158: Add coding header when notebook exported to .py file.
• 1160: don’t ignore ctrl-C during %gui qt
• 1159: Add encoding header to Python files downloaded from notebooks.
• 1155: minor post-execute fixes (#1154)
• 1153: Pager tearing bug
• 1152: Add support for displaying maptlotlib axes directly.
• 1079: Login/out button cleanups
• 1151: allow access to user_ns in prompt_manager
• 1120: updated vim-ipython (pending)
• 1150: BUG: Scrolling pager in vsplit on Mac OSX tears.
• 1149: #1148 (win32 arg_split)
• 1147: Put qtconsole forground when launching
• 1146: allow saving notebook.py next to notebook.ipynb
• 1128: fix pylab StartMenu item
• 1140: Namespaces for embedding
• 1132: [notebook] read-only: disable name field
• 1125: notebook : update logo
• 1135: allow customized template and static file paths for the notebook web app
• 1122: BUG: Issue #755 qt IPythonWidget.execute_file fails if filename contains...
• 1137: rename MPIExecLaunchers to MPILaunchers
• 1130: optionally ignore shlex’s ValueError in arg_split
• 1116: Shlex unicode
• 1073: Storemagic plugin
• 1143: Add post_install script to create start menu entries in Python 3
• 1138: Fix tests to work when ~/.config/ipython contains a symlink.
• 1121: Don’t transform function calls on IPyAutocall objects
• 1118: protect CRLF from carriage-return action
• 1105: Fix for prompts containing newlines.
• 1126: Totally remove pager when read only (notebook)
• 1091: qtconsole : allow copy with shortcut in pager
• 1114: fix magics history in two-process ipython console
• 1113: Fixing #1112 removing failing asserts for test_carriage_return and test_beep
• 1089: Support carriage return (‘r’) and beep (‘b’) characters in the qtconsole
• 1108: Completer usability 2 (rebased of pr #1082)
• 864: Two-process terminal frontend (ipython core branch)
• 1082: usability and cross browser compat for completer
• 1053: minor improvements to text placement in qtconsole
• 1106: Fix display of errors in compiled code on Python 3
• 1077: allow the notebook to run without MathJax
• 1072: If object has a getdoc() method, override its normal docstring.
• 1059: Switch to simple __IPYTHON__ global
• 1070: Execution count after SyntaxError
• 1098: notebook: config section UI
• 1101: workaround spawnb missing from pexpect.__all__
• 1097: typo, should fix #1095
• 1099: qtconsole export xhtml/utf8
• 1083: Prompts
• 1081: Fix wildcard search for updated namespaces
• 1084: write busy in notebook window title...
• 768: codepage handling of output from scripts and shellcommands are not handled properly by qt-
console
• 785: Don’t strip leading whitespace in repr() in notebook
• 737: in pickleshare.py line52 should be “if not os.path.isdir(self.root):”?
• 738: in ipthon_win_post_install.py line 38
• 777: print(. . . , sep=. . . ) raises SyntaxError
• 728: ipcontroller crash with MPI
• 780: qtconsole Out value prints before the print statements that precede it
• 632: IPython Crash Report (0.10.2)
• 253: Unable to install ipython on windows
• 80: Split IPClusterApp into multiple Application subclasses for each subcommand
• 34: non-blocking pendingResult partial results
• 739: Tests fail if tornado not installed
• 719: Better support Pypy
• 667: qtconsole problem with default pylab profile
• 661: ipythonrc referenced in magic command in 0.11
• 665: Source introspection with ?? is broken
• 724: crash - ipython qtconsole, %quickref
• 655: ipython with qtconsole crashes
• 593: HTML Notebook Prompt can be deleted . . .
• 563: use argparse instead of kvloader for flags&aliases
• 751: Tornado version greater than 2.0 needed for firefox 6
• 720: Crash report when importing easter egg
• 740: Ctrl-Enter clears line in notebook
• 772: ipengine fails on Windows with “XXX lineno: 355, opcode: 0”
• 771: Add python 3 tag to setup.py
• 767: non-ascii in __doc__ string crashes qtconsole kernel when showing tooltip
• 733: In Windows, %run fails to strip quotes from filename
• 721: no completion in emacs by ipython(ipython.el)
• 669: Do not accept an ipython_dir that’s not writeable
• 711: segfault on mac os x
• 500: “RuntimeError: Cannot change input buffer during execution” in console_widget.py
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
0.11 Series
Release 0.11
IPython 0.11 is a major overhaul of IPython, two years in the making. Most of the code base has been
rewritten or at least reorganized, breaking backward compatibility with several APIs in previous versions. It
is the first major release in two years, and probably the most significant change to IPython since its inception.
We plan to have a relatively quick succession of releases, as people discover new bugs and regressions. Once
we iron out any significant bugs in this process and settle down the new APIs, this series will become IPython
1.0. We encourage feedback now on the core APIs, which we hope to maintain stable during the 1.0 series.
Since the internal APIs have changed so much, projects using IPython as a library (as opposed to end-users
of the application) are the most likely to encounter regressions or changes that break their existing use
patterns. We will make every effort to provide updated versions of the APIs to facilitate the transition, and
we encourage you to contact us on the development mailing list with questions and feedback.
Chris Fonnesbeck recently wrote an excellent post that highlights some of our major new features, with
examples and screenshots. We encourage you to read it as it provides an illustrated, high-level overview
complementing the detailed feature breakdown in this document.
A quick summary of the major changes (see below for details):
• Standalone Qt console: a new rich console has been added to IPython, started with ipython
qtconsole. In this application we have tried to retain the feel of a terminal for fast and efficient
workflows, while adding many features that a line-oriented terminal simply can not support, such as
inline figures, full multiline editing with syntax highlighting, graphical tooltips for function calls and
much more. This development was sponsored by Enthought Inc.. See below for details.
• High-level parallel computing with ZeroMQ. Using the same architecture that our Qt console is
based on, we have completely rewritten our high-level parallel computing machinery that in prior
versions used the Twisted networking framework. While this change will require users to update
their codes, the improvements in performance, memory control and internal consistency across our
codebase convinced us it was a price worth paying. We have tried to explain how to best proceed with
this update, and will be happy to answer questions that may arise. A full tutorial describing these
features was presented at SciPy‘11, more details below.
• New model for GUI/plotting support in the terminal. Now instead of the various -Xthread flags
we had before, GUI support is provided without the use of any threads, by directly integrating GUI
event loops with Python’s PyOS_InputHook API. A new command-line flag --gui controls GUI
support, and it can also be enabled after IPython startup via the new %gui magic. This requires some
changes if you want to execute GUI-using scripts inside IPython, see the GUI support section for
more details.
• A two-process architecture. The Qt console is the first use of a new model that splits IPython
between a kernel process where code is executed and a client that handles user interaction. We plan
on also providing terminal and web-browser based clients using this infrastructure in future releases.
This model allows multiple clients to interact with an IPython process through a well-documented
messaging protocol using the ZeroMQ networking library.
• Refactoring. the entire codebase has been refactored, in order to make it more modular and easier
to contribute to. IPython has traditionally been a hard project to participate because the old codebase
was very monolithic. We hope this (ongoing) restructuring will make it easier for new developers to
join us.
• Vim integration. Vim can be configured to seamlessly control an IPython kernel, see the files in
docs/examples/vim for the full details. This work was done by Paul Ivanov, who prepared a
nice video demonstration of the features it provides.
• Integration into Microsoft Visual Studio. Thanks to the work of the Microsoft Python Tools for
Visual Studio team, this version of IPython has been integrated into Microsoft Visual Studio’s Python
tools open source plug-in. Details below
• Improved unicode support. We closed many bugs related to unicode input.
• Python 3. IPython now runs on Python 3.x. See Python 3 support for details.
• New profile model. Profiles are now directories that contain all relevant information for that session,
and thus better isolate IPython use-cases.
• SQLite storage for history. All history is now stored in a SQLite database, providing support for
multiple simultaneous sessions that won’t clobber each other as well as the ability to perform queries
on all stored data.
• New configuration system. All parts of IPython are now configured via a mechanism inspired by the
Enthought Traits library. Any configurable element can have its attributes set either via files that now
use real Python syntax or from the command-line.
• Pasting of code with prompts. IPython now intelligently strips out input prompts , be they plain
Python ones (>>> and ...) or IPython ones (In [N]: and ...:). More details here.
Over 60 separate authors have contributed to this release, see below for a full list. In particular, we want to
highlight the extremely active participation of two new core team members: Evan Patterson implemented the
Qt console, and Thomas Kluyver started with our Python 3 port and by now has made major contributions
to just about every area of IPython.
We are also grateful for the support we have received during this development cycle from several institutions:
• Enthought Inc funded the development of our new Qt console, an effort that required developing
major pieces of underlying infrastructure, which now power not only the Qt console but also our new
parallel machinery. We’d like to thank Eric Jones and Travis Oliphant for their support, as well as Ilan
Schnell for his tireless work integrating and testing IPython in the Enthought Python Distribution.
• Nipy/NIH: funding via the NiPy project (NIH grant 5R01MH081909-02) helped us jumpstart the
development of this series by restructuring the entire codebase two years ago in a way that would
make modular development and testing more approachable. Without this initial groundwork, all the
new features we have added would have been impossible to develop.
• Sage/NSF: funding via the grant Sage: Unifying Mathematical Software for Scientists, Engineers,
and Mathematicians (NSF grant DMS-1015114) supported a meeting in spring 2011 of several of the
core IPython developers where major progress was made integrating the last key pieces leading to this
release.
• Microsoft’s team working on Python Tools for Visual Studio developed the integraton of IPython into
the Python plugin for Visual Studio 2010.
• Google Summer of Code: in 2010, we had two students developing prototypes of the new machinery
that is now maturing in this release: Omar Zapata and Gerardo Gutiérrez.
In April 2010, after one breakage too many with bzr, we decided to move our entire development process
to Git and Github.com. This has proven to be one of the best decisions in the project’s history, as the
combination of git and github have made us far, far more productive than we could be with our previous
tools. We first converted our bzr repo to a git one without losing history, and a few weeks later ported all
open Launchpad bugs to github issues with their comments mostly intact (modulo some formatting changes).
This ensured a smooth transition where no development history or submitted bugs were lost. Feel free to
use our little Launchpad to Github issues porting script if you need to make a similar transition.
These simple statistics show how much work has been done on the new release, by comparing the current
code to the last point it had in common with the 0.10 series. A huge diff and ~2200 commits make up this
cycle:
Since our move to github, 511 issues were closed, 226 of which were pull requests and 285 regular issues (a
full list with links is available for those interested in the details). Github’s pull requests are a fantastic mech-
anism for reviewing code and building a shared ownership of the project, and we are making enthusiastic
use of it.
Note: This undercounts the number of issues closed in this development cycle, since we only moved to
github for issue tracking in May 2010, but we have no way of collecting statistics on the number of issues
closed in the old Launchpad bug tracker prior to that.
Qt Console
IPython now ships with a Qt application that feels very much like a terminal, but is in fact a rich GUI that
runs an IPython client but supports inline figures, saving sessions to PDF and HTML, multiline editing with
syntax highlighting, graphical calltips and much more:
We hope that many projects will embed this widget, which we’ve kept deliberately very lightweight, into
their own environments. In the future we may also offer a slightly more featureful application (with menus
and other GUI elements), but we remain committed to always shipping this easy to embed widget.
See the Qt console section of the docs for a detailed description of the console’s features and use.
We have completely rewritten the Twisted-based code for high-level parallel computing to work atop our
new ZeroMQ architecture. While we realize this will break compatibility for a number of users, we hope
to make the transition as easy as possible with our docs, and we are convinced the change is worth it.
ZeroMQ provides us with much tighter control over memory, higher performance, and its communications
are impervious to the Python Global Interpreter Lock because they take place in a system-level C++ thread.
The impact of the GIL in our previous code was something we could simply not work around, given that
Twisted is itself a Python library. So while Twisted is a very capable framework, we think ZeroMQ fits our
needs much better and we hope you will find the change to be a significant improvement in the long run.
Our manual contains a full description of how to use IPython for parallel computing, and the tutorial pre-
sented by Min Ragan-Kelley at the SciPy 2011 conference provides a hands-on complement to the reference
docs.
Fig. 2.5: The Qt console for IPython, using inline matplotlib plots.
Refactoring
As of this release, a signifiant portion of IPython has been refactored. This refactoring is founded on a
number of new abstractions. The main new classes that implement these abstractions are:
• IPython.utils.traitlets.HasTraits.
• IPython.config.configurable.Configurable.
• IPython.config.application.Application.
• IPython.config.loader.ConfigLoader.
• IPython.config.loader.Config
We are still in the process of writing developer focused documentation about these classes, but for now our
configuration documentation contains a high level overview of the concepts that these classes express.
The biggest user-visible change is likely the move to using the config system to determine the command-line
arguments for IPython applications. The benefit of this is that all configurable values in IPython are exposed
on the command-line, but the syntax for specifying values has changed. The gist is that assigning values is
pure Python assignment. Simple flags exist for commonly used options, these are always prefixed with ‘–‘.
The IPython command-line help has the details of all the options (via ipythyon --help), but a simple
example should clarify things; the pylab flag can be used to start in pylab mode with the qt4 backend:
ipython --pylab=qt
ipython --TerminalIPythonApp.pylab=qt
ZeroMQ architecture
There is a new GUI framework for IPython, based on a client-server model in which multiple clients can
communicate with one IPython kernel, using the ZeroMQ messaging framework. There is already a Qt
console client, which can be started by calling ipython qtconsole. The protocol is documented.
The parallel computing framework has also been rewritten using ZMQ. The protocol is described here, and
the code is in the new IPython.parallel module.
Python 3 support
A Python 3 version of IPython has been prepared. For the time being, this is maintained separately and
updated from the main codebase. Its code can be found here. The parallel computing components are not
perfect on Python3, but most functionality appears to be working. As this work is evolving quickly, the best
place to find updated information about it is our Python 3 wiki page.
Unicode
Entering non-ascii characters in unicode literals (u"Cø") now works properly on all platforms. However,
entering these in byte/string literals ("Cø") will not work as expected on Windows (or any platform where
the terminal encoding is not UTF-8, as it typically is for Linux & Mac OS X). You can use escape sequences
("\xe9\x82") to get bytes above 128, or use unicode literals and encode them. This is a limitation of
Python 2 which we cannot easily work around.
IPython can be used as the interactive shell in the Python plugin for Microsoft Visual Studio, as seen here:
The Microsoft team developing this currently has a release candidate out using IPython 0.11. We will
continue to collaborate with them to ensure that as they approach their final release date, the integration
with IPython remains smooth. We’d like to thank Dino Viehland and Shahrokh Mortazavi for the work they
have done towards this feature, as well as Wenming Ye for his support of our WinHPC capabilities.
• Added Bytes traitlet, removing Str. All ‘string’ traitlets should either be Unicode if a real string,
or Bytes if a C-string. This removes ambiguity and helps the Python 3 transition.
• New magic %loadpy loads a python file from disk or web URL into the current input buffer.
• New magic %pastebin for sharing code via the ‘Lodge it’ pastebin.
• New magic %precision for controlling float and numpy pretty printing.
• IPython applications initiate logging, so any object can gain access to a the logger of the currently
running Application with:
• You can now get help on an object halfway through typing a command. For instance, typing a =
zip? shows the details of zip(). It also leaves the command at the next prompt so you can carry
on with it.
• The input history is now written to an SQLite database. The API for retrieving items from the history
has also been redesigned.
• The IPython.extensions.pretty extension has been moved out of quarantine and fully up-
dated to the new extension API.
• New magics for loading/unloading/reloading extensions have been added: %load_ext,
%unload_ext and %reload_ext.
• The configuration system and configuration files are brand new. See the configuration system docu-
mentation for more details.
• The InteractiveShell class is now a Configurable subclass and has traitlets that determine
the defaults and runtime environment. The __init__ method has also been refactored so this class
can be instantiated and run without the old ipmaker module.
• The methods of InteractiveShell have been organized into sections to make it easier to turn
more sections of functionality into components.
• The embedded shell has been refactored into a truly standalone subclass of InteractiveShell
called InteractiveShellEmbed. All embedding logic has been taken out of the base class and
put into the embedded subclass.
• Added methods of InteractiveShell to help it cleanup after itself. The cleanup() method
controls this. We couldn’t do this in __del__() because we have cycles in our object graph that
prevent it from being called.
• Created a new module IPython.utils.importstring for resolving strings like foo.bar.
Bar to the actual class.
• Completely refactored the IPython.core.prefilter module into Configurable sub-
classes. Added a new layer into the prefilter system, called “transformations” that all new prefilter
logic should use (rather than the older “checker/handler” approach).
• Aliases are now components (IPython.core.alias).
• New top level embed() function that can be called to embed IPython at any place in user’s code. On
the first call it will create an InteractiveShellEmbed instance and call it. In later calls, it just
calls the previously created InteractiveShellEmbed.
• Created a configuration system (IPython.config.configurable) that is based on
IPython.utils.traitlets. Configurables are arranged into a runtime containment tree (not
inheritance) that i) automatically propagates configuration information and ii) allows singletons to
discover each other in a loosely coupled manner. In the future all parts of IPython will be subclasses
of Configurable. All IPython developers should become familiar with the config system.
• Created a new Config for holding configuration information. This is a dict like class with a few ex-
tras: i) it supports attribute style access, ii) it has a merge function that merges two Config instances
recursively and iii) it will automatically create sub-Config instances for attributes that start with an
uppercase character.
• Created new configuration loaders in IPython.config.loader. These loaders provide a unified
loading interface for all configuration information including command line arguments and configura-
tion files. We have two default implementations based on argparse and plain python files. These
are used to implement the new configuration system.
• Created a top-level Application class in IPython.core.application that is designed to
encapsulate the starting of any basic Python program. An application loads and merges all the config-
uration objects, constructs the main application, configures and initiates logging, and creates and
configures any Configurable instances and then starts the application running. An extended
BaseIPythonApplication class adds logic for handling the IPython directory as well as pro-
files, and all IPython entry points extend it.
• The Type and Instance traitlets now handle classes given as strings, like foo.bar.Bar. This
is needed for forward declarations. But, this was implemented in a careful way so that string to class
resolution is done at a single point, when the parent HasTraitlets is instantiated.
• IPython.utils.ipstruct has been refactored to be a subclass of dict. It also now has full
docstrings and doctests.
• Created a Traits like implementation in IPython.utils.traitlets. This is a pure Python,
lightweight version of a library that is similar to Enthought’s Traits project, but has no dependencies
on Enthought’s code. We are using this for validation, defaults and notification in our new component
system. Although it is not 100% API compatible with Enthought’s Traits, we plan on moving in
this direction so that eventually our implementation could be replaced by a (yet to exist) pure Python
version of Enthought Traits.
• Added a new module IPython.lib.inputhook to manage the integration with GUI event loops
using PyOS_InputHook. See the docstrings in this module or the main IPython docs for details.
• For users, GUI event loop integration is now handled through the new %gui magic command. Type
%gui? at an IPython prompt for documentation.
• For developers IPython.lib.inputhook provides a simple interface for managing the event
loops in their interactive GUI applications. Examples can be found in our examples/lib directory.
• The Twisted-based IPython.kernel has been removed, and completely rewritten as IPython.
parallel, using ZeroMQ.
• Profiles are now directories. Instead of a profile being a single config file, profiles are now self-
contained directories. By default, profiles get their own IPython history, log files, and everything. To
create a new profile, do ipython profile create <name>.
• All IPython applications have been rewritten to use KeyValueConfigLoader. This means that
command-line options have changed. Now, all configurable values are accessible from the command-
line with the same syntax as in a configuration file.
• The command line options -wthread, -qthread and -gthread have been removed. Use
--gui=wx, --gui=qt, --gui=gtk instead.
• The extension loading functions have been renamed to load_ipython_extension() and
unload_ipython_extension().
• InteractiveShell no longer takes an embedded argument. Instead just use the
InteractiveShellEmbed class.
• __IPYTHON__ is no longer injected into __builtin__.
• Struct.__init__() no longer takes None as its first argument. It must be a dict or Struct.
• ipmagic() has been renamed ()
• The functions ipmagic() and ipalias() have been removed from __builtins__.
• The references to the global InteractiveShell instance (_ip, and __IP) have been removed
from the user’s namespace. They are replaced by a new function called get_ipython() that re-
turns the current InteractiveShell instance. This function is injected into the user’s namespace
and is now the main way of accessing the running IPython.
• Old style configuration files ipythonrc and ipy_user_conf.py are no longer supported. Users
should migrate there configuration files to the new format described here and here.
• The old IPython extension API that relied on ipapi() has been completely removed. The new
extension API is described here.
• Support for qt3 has been dropped. Users who need this should use previous versions of IPython.
• Removed shellglobals as it was obsolete.
• Removed all the threaded shells in IPython.core.shell. These are no longer needed because
of the new capabilities in IPython.lib.inputhook.
• New top-level sub-packages have been created: IPython.core, IPython.lib, IPython.
utils, IPython.deathrow, IPython.quarantine. All existing top-level modules have
been moved to appropriate sub-packages. All internal import statements have been updated and tests
have been added. The build system (setup.py and friends) have been updated. See The IPython API
for details of these new sub-packages.
• IPython.ipapi has been moved to IPython.core.ipapi. IPython.Shell and
IPython.iplib have been split and removed as part of the refactor.
• Extensions has been moved to extensions and all existing extensions have been moved to
either IPython.quarantine or IPython.deathrow. IPython.quarantine contains
modules that we plan on keeping but that need to be updated. IPython.deathrow contains mod-
ules that are either dead or that should be maintained as third party libraries.
• Previous IPython GUIs in IPython.frontend and IPython.gui are likely broken, and have
been removed to IPython.deathrow because of the refactoring in the core. With proper updates,
these should still work.
Known Regressions
We do our best to improve IPython, but there are some known regressions in 0.11 relative to 0.10.2. First
of all, there are features that have yet to be ported to the new APIs, and in order to ensure that all of the
installed code runs for our users, we have moved them to two separate directories in the source distribution,
quarantine and deathrow. Finally, we have some other miscellaneous regressions that we hope to fix
as soon as possible. We now describe all of these in more detail.
Quarantine
These are tools and extensions that we consider relatively easy to update to the new classes and APIs, but
that we simply haven’t had time for. Any user who is interested in one of these is encouraged to help us by
porting it and submitting a pull request on our development site.
Currently, the quarantine directory contains:
Deathrow
These packages may be harder to update or make most sense as third-party libraries. Some of them are
completely obsolete and have been already replaced by better functionality (we simply haven’t had the time
to carefully weed them out so they are kept here for now). Others simply require fixes to code that the
current core team may not be familiar with. If a tool you were used to is included here, we encourage you to
contact the dev list and we can discuss whether it makes sense to keep it in IPython (if it can be maintained).
Currently, the deathrow directory contains:
Other regressions
• The machinery that adds functionality to the ‘sh’ profile for using IPython as your system shell has
not been updated to use the new APIs. As a result, only the aesthetic (prompt) changes are still
implemented. We intend to fix this by 0.12. Tracked as issue 547.
• The installation of scripts on Windows was broken without setuptools, so we now depend on se-
tuptools on Windows. We hope to fix setuptools-less installation, and then remove the setuptools
dependency. Issue 539.
• The directory history _dh is not saved between sessions. Issue 634.
Removed Features
As part of the updating of IPython, we have removed a few features for the purposes of cleaning up the code-
base and interfaces. These removals are permanent, but for any item listed below, equivalent functionality
is available.
• The magics Exit and Quit have been dropped as ways to exit IPython. Instead, the lowercase forms of
both work either as a bare name (exit) or a function call (exit()). You can assign these to other
names using exec_lines in the config file.
Credits
Many users and developers contributed code, features, bug reports and ideas to this release. Please do not
hesitate in contacting us if we’ve failed to acknowledge your contribution here. In particular, for this release
we have contribution from the following people, a mix of new and regular names (in alphabetical order by
first name):
• Aenugu Sai Kiran Reddy <saikrn08-at-gmail.com>
• andy wilson <wilson.andrew.j+github-at-gmail.com>
• Antonio Cuni <antocuni>
• Barry Wark <barrywark-at-gmail.com>
• Beetoju Anuradha <anu.beethoju-at-gmail.com>
• Benjamin Ragan-Kelley <minrk-at-Mercury.local>
• Brad Reisfeld
• Brian E. Granger <ellisonbg-at-gmail.com>
• Christoph Gohlke <cgohlke-at-uci.edu>
• Cody Precord
• dan.milstein
• Darren Dale <dsdale24-at-gmail.com>
• Dav Clark <davclark-at-berkeley.edu>
• Ramana <sramana9-at-gmail.com>
• Robert Kern <robert.kern-at-gmail.com>
• Sathesh Chandra <satheshchandra88-at-gmail.com>
• Satrajit Ghosh <satra-at-mit.edu>
• Sebastian Busch
• Skipper Seabold <jsseabold-at-gmail.com>
• Stefan van der Walt <bzr-at-mentat.za.net>
• Stephan Peijnik <debian-at-sp.or.at>
• Steven Bethard
• Thomas Kluyver <takowl-at-gmail.com>
• Thomas Spura <tomspur-at-fedoraproject.org>
• Tom Fetherston <tfetherston-at-aol.com>
• Tom MacWright
• tzanko
• vankayala sowjanya <hai.sowjanya-at-gmail.com>
• Vivian De Smedt <vds2212-at-VIVIAN>
• Ville M. Vainio <vivainio-at-gmail.com>
• Vishal Vatsa <vishal.vatsa-at-gmail.com>
• Vishnu S G <sgvishnu777-at-gmail.com>
• Walter Doerwald <walter-at-livinglogic.de>
Note: This list was generated with the output of git log dev-0.11 HEAD --format='* %aN
<%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u after some cleanup. If you
should be on this list, please add yourself.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
In this cycle, we closed a total of 511 issues, 226 pull requests and 285 regular issues; this is the full list
(generated with the script tools/github_stats.py). We should note that a few of these were made
on the 0.10.x series, but we have no automatic way of filtering the issues by branch, so this reflects all of our
development over the last two years, including work already released in 0.10.2:
• 490: fix UnicodeEncodeError writing SVG string to .svg file, fixes #489
• 491: add QtConsoleApp using newapplication
• 479: embed() doesn’t load default config
• 483: Links launchpad -> github
• 419: %xdel magic
• 477: Add n to lines in the log
• 459: use os.system for shell.system in Terminal frontend
• 475: i473
• 471: Add test decorator onlyif_unicode_paths.
• 474: Fix support for raw GTK and WX matplotlib backends.
• 472: Kernel event loop is robust against random SIGINT.
• 460: Share code for magic_edit
• 469: Add exit code when running all tests with iptest.
• 464: Add home directory expansion to IPYTHON_DIR environment variables.
• 455: Bugfix with logger
• 448: Separate out skip_doctest decorator
• 453: Draft of new main BaseIPythonApplication.
• 452: Use list/tuple/dict/set subclass’s overridden __repr__ instead of the pretty
• 398: allow toggle of svg/png inline figure format
• 381: Support inline PNGs of matplotlib plots
• 413: Retries and Resubmit (#411 and #412)
• 370: Fixes to the display system
• 449: Fix issue 447 - inspecting old-style classes.
• 423: Allow type checking on elements of List,Tuple,Set traits
• 400: Config5
• 421: Generalise mechanism to put text at the next prompt in the Qt console.
• 443: pinfo code duplication
• 429: add check_pid, and handle stale PID info in ipcluster.
• 431: Fix error message in test_irunner
• 427: handle different SyntaxError messages in test_irunner
• 424: Irunner test failure
• 430: Small parallel doc typo
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
0.10 series
Release 0.10.2
IPython 0.10.2 was released April 9, 2011. This is a minor bugfix release that preserves backward com-
patibility. At this point, all IPython development resources are focused on the 0.11 series that includes a
complete architectural restructuring of the project as well as many new capabilities, so this is likely to be the
last release of the 0.10.x series. We have tried to fix all major bugs in this series so that it remains a viable
platform for those not ready yet to transition to the 0.11 and newer codebase (since that will require some
porting effort, as a number of APIs have changed).
Thus, we are not opening a 0.10.3 active development branch yet, but if the user community requires new
patches and is willing to maintain/release such a branch, we’ll be happy to host it on the IPython github
repositories.
Highlights of this release:
• The main one is the closing of github ticket #185, a major regression we had in 0.10.1 where pylab
mode with GTK (or gthread) was not working correctly, hence plots were blocking with GTK. Since
this is the default matplotlib backend on Unix systems, this was a major annoyance for many users.
Many thanks to Paul Ivanov for helping resolve this issue.
• Fix IOError bug on Windows when used with -gthread.
• Work robustly if $HOME is missing from environment.
• Better POSIX support in ssh scripts (remove bash-specific idioms).
• Improved support for non-ascii characters in log files.
• Work correctly in environments where GTK can be imported but not started (such as a linux text
console without X11).
For this release we merged 24 commits, contributed by the following people (please let us know if we
ommitted your name and we’ll gladly fix this in the notes for the future):
• Fernando Perez
• MinRK
• Paul Ivanov
Release 0.10.1
IPython 0.10.1 was released October 11, 2010, over a year after version 0.10. This is mostly a bugfix release,
since after version 0.10 was released, the development team’s energy has been focused on the 0.11 series.
We have nonetheless tried to backport what fixes we could into 0.10.1, as it remains the stable series that
many users have in production systems they rely on.
Since the 0.11 series changes many APIs in backwards-incompatible ways, we are willing to continue main-
taining the 0.10.x series. We don’t really have time to actively write new code for 0.10.x, but we are happy
to accept patches and pull requests on the IPython github site. If sufficient contributions are made that im-
prove 0.10.1, we will roll them into future releases. For this purpose, we will have a branch called 0.10.2 on
github, on which you can base your contributions.
For this release, we applied approximately 60 commits totaling a diff of over 7000 lines:
• A long-standing and quite annoying bug where parentheses would be added to print statements,
under Python 2.5 and 2.6, was finally fixed.
• Improved handling of libreadline on Apple OSX.
• Fix reload method of IPython demos, which was broken.
• Fixes for the ipipe/ibrowse system on OSX.
• Fixes for Zope profile.
• Fix %timeit reporting when the time is longer than 1000s.
• Avoid lockups with ? or ?? in SunOS, due to a bug in termios.
• The usual assortment of miscellaneous bug fixes and small improvements.
The following people contributed to this release (please let us know if we omitted your name and we’ll
gladly fix this in the notes for the future):
• Beni Cherniavsky
• Boyd Waters.
• David Warde-Farley
• Fernando Perez
• Gökhan Sever
• John Hunter
• Justin Riley
• Kiorky
• Laurent Dufrechou
• Mark E. Smith
• Matthieu Brucher
• Satrajit Ghosh
• Sebastian Busch
• Václav Šmilauer
Release 0.10
This release brings months of slow but steady development, and will be the last before a major restructuring
and cleanup of IPython’s internals that is already under way. For this reason, we hope that 0.10 will be
a stable and robust release so that while users adapt to some of the API changes that will come with the
refactoring that will become IPython 0.11, they can safely use 0.10 in all existing projects with minimal
changes (if any).
IPython 0.10 is now a medium-sized project, with roughly (as reported by David Wheeler’s sloccount
utility) 40750 lines of Python code, and a diff between 0.9.1 and this release that contains almost 28000
lines of code and documentation. Our documentation, in PDF format, is a 495-page long PDF document
(also available in HTML format, both generated from the same sources).
Many users and developers contributed code, features, bug reports and ideas to this release. Please do not
hesitate in contacting us if we’ve failed to acknowledge your contribution here. In particular, for this release
we have contribution from the following people, a mix of new and regular names (in alphabetical order by
first name):
• Alexander Clausen: fix #341726.
• Brian Granger: lots of work everywhere (features, bug fixes, etc).
• Daniel Ashbrook: bug report on MemoryError during compilation, now fixed.
• Darren Dale: improvements to documentation build system, feedback, design ideas.
• Fernando Perez: various places.
• Gaël Varoquaux: core code, ipythonx GUI, design discussions, etc. Lots...
• John Hunter: suggestions, bug fixes, feedback.
• Jorgen Stenarson: work on many fronts, tests, fixes, win32 support, etc.
• Laurent Dufréchou: many improvements to ipython-wx standalone app.
• Lukasz Pankowski: prefilter, %edit, demo improvements.
• Matt Foster: TextMate support in %edit.
• Nathaniel Smith: fix #237073.
• Pauli Virtanen: fixes and improvements to extensions, documentation.
• Prabhu Ramachandran: improvements to %timeit.
• Robert Kern: several extensions.
• Sameer D’Costa: help on critical bug #269966.
• Stephan Peijnik: feedback on Debian compliance and many man pages.
• Steven Bethard: we are now shipping his argparse module.
• Tom Fetherston: many improvements to IPython.demo module.
• Ville Vainio: lots of work everywhere (features, bug fixes, etc).
• Vishal Vasta: ssh support in ipcluster.
• Walter Doerwald: work on the IPython.ipipe system.
Below we give an overview of new features, bug fixes and backwards-incompatible changes. For a detailed
account of every change made, feel free to view the project log with bzr log.
New features
• New %paste magic automatically extracts current contents of clipboard and pastes it directly, while
correctly handling code that is indented or prepended with >>> or ... python prompt markers. A
• %edit: If you do ‘%edit pasted_block’, pasted_block variable gets updated with new data (so repeated
editing makes sense)
Bug fixes
• Fix #368719, removed top-level debian/ directory to make the job of Debian packagers easier.
• Fix #291143 by including man pages contributed by Stephan Peijnik from the Debian project.
• Fix #358202, effectively a race condition, by properly synchronizing file creation at cluster startup
time.
• %timeit now handles correctly functions that take a long time to execute even the first time, by not
repeating them.
• Fix #239054, releasing of references after exiting.
• Fix #341726, thanks to Alexander Clausen.
• Fix #269966. This long-standing and very difficult bug (which is actually a problem in Python itself)
meant long-running sessions would inevitably grow in memory size, often with catastrophic conse-
quences if users had large objects in their scripts. Now, using %run repeatedly should not cause any
memory leaks. Special thanks to John Hunter and Sameer D’Costa for their help with this bug.
• Fix #295371, bug in %history.
• Improved support for py2exe.
• Fix #270856: IPython hangs with PyGTK
• Fix #270998: A magic with no docstring breaks the ‘%magic magic’
• fix #271684: -c startup commands screw up raw vs. native history
• Numerous bugs on Windows with the new ipcluster have been fixed.
• The ipengine and ipcontroller scripts now handle missing furl files more gracefully by giving better
error messages.
• %rehashx: Aliases no longer contain dots. python3.0 binary will create alias python30. Fixes:
#259716 “commands with dots in them don’t work”
• %cpaste: %cpaste -r repeats the last pasted block. The block is assigned to pasted_block even if code
raises exception.
• Bug #274067 ‘The code in get_home_dir is broken for py2exe’ was fixed.
• Many other small bug fixes not listed here by number (see the bzr log for more info).
• ipykit and related files were unmaintained and have been removed.
• The IPython.genutils.doctest_reload() does not actually call reload(doctest)
anymore, as this was causing many problems with the test suite. It still resets doctest.master to
None.
• While we have not deliberately broken Python 2.4 compatibility, only minor testing was done with
Python 2.4, while 2.5 and 2.6 were fully tested. But if you encounter problems with 2.4, please do
report them as bugs.
• The ipcluster now requires a mode argument; for example to start a cluster on the local machine
with 4 engines, you must now type:
$ ipcluster local -n 4
• The controller now has a -r flag that needs to be used if you want to reuse existing furl files. Other-
wise they are deleted (the default).
• Remove ipy_leo.py. You can use easy_install ipython-extension to get it. (done to
decouple it from ipython release cycle)
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
0.9 series
Release 0.9.1
This release was quickly made to restore compatibility with Python 2.4, which version 0.9 accidentally
broke. No new features were introduced, other than some additional testing support for internal use.
Release 0.9
New features
• All furl files and security certificates are now put in a read-only directory named ~/.ipython/security.
• A single function get_ipython_dir(), in IPython.genutils that determines the user’s
IPython directory in a robust manner.
• Laurent’s WX application has been given a top-level script called ipython-wx, and it has received
numerous fixes. We expect this code to be architecturally better integrated with Gael’s WX ‘ipython
widget’ over the next few releases.
• The Editor synchronization work by Vivian De Smedt has been merged in. This code adds a number
of new editor hooks to synchronize with editors under Windows.
• A new, still experimental but highly functional, WX shell by Gael Varoquaux. This work was spon-
sored by Enthought, and while it’s still very new, it is based on a more cleanly organized arhictecture
of the various IPython components. We will continue to develop this over the next few releases as a
model for GUI components that use IPython.
• Another GUI frontend, Cocoa based (Cocoa is the OSX native GUI framework), authored by Barry
Wark. Currently the WX and the Cocoa ones have slightly different internal organizations, but the
whole team is working on finding what the right abstraction points are for a unified codebase.
• As part of the frontend work, Barry Wark also implemented an experimental event notification system
that various ipython components can use. In the next release the implications and use patterns of this
system regarding the various GUI options will be worked out.
• IPython finally has a full test system, that can test docstrings with IPython-specific functionality.
There are still a few pieces missing for it to be widely accessible to all users (so they can run the test
suite at any time and report problems), but it now works for the developers. We are working hard on
continuing to improve it, as this was probably IPython’s major Achilles heel (the lack of proper test
coverage made it effectively impossible to do large-scale refactoring). The full test suite can now be
run using the iptest command line program.
• The notion of a task has been completely reworked. An ITask interface has been created. This
interface defines the methods that tasks need to implement. These methods are now responsible for
things like submitting tasks and processing results. There are two basic task types: IPython.
kernel.task.StringTask (this is the old Task object, but renamed) and the new IPython.
kernel.task.MapTask, which is based on a function.
• A new interface, IPython.kernel.mapper.IMapper has been defined to standardize the idea
of a map method. This interface has a single map method that has the same syntax as the built-in map.
We have also defined a mapper factory interface that creates objects that implement IPython.
kernel.mapper.IMapper for different controllers. Both the multiengine and task controller
now have mapping capabilties.
• The parallel function capabilities have been reworks. The major changes are that i) there is now an
@parallel magic that creates parallel functions, ii) the syntax for multiple variable follows that of
map, iii) both the multiengine and task controller now have a parallel function implementation.
• All of the parallel computing capabilities from ipython1-dev have been merged into IPython
proper. This resulted in the following new subpackages: IPython.kernel, IPython.kernel.
core, IPython.config, IPython.tools and IPython.testing.
• As part of merging in the ipython1-dev stuff, the setup.py script and friends have been com-
pletely refactored. Now we are checking for dependencies using the approach that matplotlib uses.
• The documentation has been completely reorganized to accept the documentation from
ipython1-dev.
• We have switched to using Foolscap for all of our network protocols in IPython.kernel. This
gives us secure connections that are both encrypted and authenticated.
• We have a brand new COPYING.txt files that describes the IPython license and copyright. The
biggest change is that we are putting “The IPython Development Team” as the copyright holder. We
give more details about exactly what this means in this file. All developer should read this and use the
new banner in all IPython source code files.
Bug fixes
• The Windows installer has been fixed. Now all IPython scripts have .bat versions created. Also, the
Start Menu shortcuts have been updated.
• The colors escapes in the multiengine client are now turned off on win32 as they don’t print correctly.
• The IPython.kernel.scripts.ipengine script was exec’ing mpi_import_statement incor-
rectly, which was leading the engine to crash when mpi was enabled.
• A few subpackages had missing __init__.py files.
• The documentation is only created if Sphinx is found. Previously, the setup.py script would fail if
it was missing.
• Greedy cd completion has been disabled again (it was enabled in 0.8.4) as it caused problems on
certain platforms.
• The clusterfile options of the ipcluster command has been removed as it was not working
and it will be replaced soon by something much more robust.
• The IPython.kernel configuration now properly find the user’s IPython directory.
• In ipapi, the make_user_ns() function has been replaced with make_user_namespaces(),
to support dict subclasses in namespace creation.
• IPython.kernel.client.Task has been renamed IPython.kernel.client.
StringTask to make way for new task types.
• The keyword argument style has been renamed dist in scatter, gather and map.
• Renamed the values that the rename dist keyword argument can have from 'basic' to 'b'.
• IPython has a larger set of dependencies if you want all of its capabilities. See the setup.py script
for details.
• The constructors for IPython.kernel.client.MultiEngineClient and IPython.
kernel.client.TaskClient no longer take the (ip,port) tuple. Instead they take the filename
of a file that contains the FURL for that client. If the FURL file is in your IPYTHONDIR, it will be
found automatically and the constructor can be left empty.
• The asynchronous clients in IPython.kernel.asyncclient are now created using the fac-
tory functions get_multiengine_client() and get_task_client(). These return a
Deferred to the actual client.
• The command line options to ipcontroller and ipengine have changed to reflect the new
Foolscap network protocol and the FURL files. Please see the help for these scripts for details.
• The configuration files for the kernel have changed because of the Foolscap stuff. If you were using
custom config files before, you should delete them and regenerate new ones.
New features
• Much improved setup.py and setupegg.py scripts. Because Twisted and zope.interface are
now easy installable, we can declare them as dependencies in our setupegg.py script.
• IPython is now compatible with Twisted 2.5.0 and 8.x.
• Added a new example of how to use ipython1.kernel.asynclient.
• Initial draft of a process daemon in ipython1.daemon. This has not been merged into IPython
and is still in ipython1-dev.
• The TaskController now has methods for getting the queue status.
• The TaskResult objects not have information about how long the task took to run.
• We are attaching additional attributes to exceptions (_ipython_*) that we use to carry additional
info around.
• New top-level module asyncclient that has asynchronous versions (that return deferreds) of the
client classes. This is designed to users who want to run their own Twisted reactor.
• All the clients in client are now based on Twisted. This is done by running the Twisted reactor in
a separate thread and using the blockingCallFromThread() function that is in recent versions
of Twisted.
• Functions can now be pushed/pulled to/from engines using MultiEngineClient.
push_function() and MultiEngineClient.pull_function().
• Gather/scatter are now implemented in the client to reduce the work load of the controller and improve
performance.
• Complete rewrite of the IPython docuementation. All of the documentation from the IPython website
has been moved into docs/source as restructured text documents. PDF and HTML documentation are
being generated using Sphinx.
• New developer oriented documentation: development guidelines and roadmap.
• Traditional ChangeLog has been changed to a more useful changes.txt file that is organized by
release and is meant to provide something more relevant for users.
Bug fixes
• All names have been renamed to conform to the lowercase_with_underscore convention. This will
require users to change references to all names like queueStatus to queue_status.
• Previously, methods like MultiEngineClient.push() and MultiEngineClient.
push() used *args and **kwargs. This was becoming a problem as we weren’t able to introduce
new keyword arguments into the API. Now these methods simple take a dict or sequence. This has
also allowed us to get rid of the *All methods like pushAll() and pullAll(). These things are
now handled with the targets keyword argument that defaults to 'all'.
• The MultiEngineClient.magicTargets has been renamed to MultiEngineClient.
targets.
• All methods in the MultiEngine interface now accept the optional keyword argument block.
• Renamed RemoteController to MultiEngineClient and TaskController to
TaskClient.
• Renamed the top-level module from api to client.
• Most methods in the multiengine interface now raise a CompositeError exception that wraps the
user’s exceptions, rather than just raising the raw user’s exception.
• Changed the setupNS and resultNames in the Task class to push and pull.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
0.8 series
Release 0.8.4
This was a quick release to fix an unfortunate bug that slipped into the 0.8.3 release. The --twisted
option was disabled, as it turned out to be broken across several platforms.
Release 0.8.3
• pydb is now disabled by default (due to %run -d problems). You can enable it by passing -pydb
command line argument to IPython. Note that setting it in config file won’t work.
Release 0.8.2
• %pushd/%popd behave differently; now “pushd /foo” pushes CURRENT directory and jumps to /foo.
The current behaviour is closer to the documented behaviour, and should not trip anyone.
Older releases
Changes in earlier releases of IPython are described in the older file ChangeLog. Please refer to this
document for details.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Installation
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: If you need to use Python 2.6 or 3.2, you can find IPython 1.0 here.
Quickstart
If you have setuptools, the quickest way to get up and running with IPython is:
This will download and install IPython and its main optional dependencies:
• jinja2, needed for the notebook
• sphinx, needed for nbconvert
• pyzmq, needed for IPython’s parallel computing features, qt console and notebook
• pygments, used by nbconvert and the Qt console for syntax highlighting
• tornado, needed by the web-based notebook
• nose, used by the test suite
249
IPython Documentation, Release 3.0.0-dev
$ iptest
Overview
This document describes in detail the steps required to install IPython, and its various optional dependencies.
For a few quick ways to get started with package managers or full Python distributions, see the install page
of the IPython website.
IPython is organized into a number of subpackages, each of which has its own dependencies. All of the
subpackages come with IPython, so you don’t need to download and install them separately. However, to
use a given subpackage, you will need to install all of its dependencies.
Please let us know if you have problems installing IPython or any of its dependencies.
IPython and most dependencies can be installed via pip. In many scenarios, this is the simplest method of
installing Python packages. More information about pip can be found on its PyPI page.
Note: On Windows, IPython requires setuptools. We hope to change this in the future, but for now on
Windows, you must install setuptools to use IPython.
More general information about installing Python packages can be found in Python’s documentation.
Given a properly built Python, the basic interactive IPython shell will work with no external dependencies.
However, some Python distributions (particularly on Windows and OS X), don’t come with a working
readline module. The IPython shell will work without readline, but will lack many features that users
depend on, such as tab completion and command line editing. If you install IPython with setuptools,
(e.g. with pip), then the appropriate readline for your platform will be installed. See below for details
of how to make sure you have a working readline.
If you have setuptools or pip, the easiest way of getting IPython is to simply use pip:
That’s it.
If you don’t want to use pip, or don’t have it installed, just grab the latest stable build of IPython from here.
Then do the following:
If you are installing to a location (like /usr/local) that requires higher permissions, you may need to
run the last command with sudo.
Windows
As mentioned above, on Windows, IPython requires setuptools, and it also requires the PyReadline
library to properly support coloring and keyboard management (features that the default windows console
doesn’t have). So on Windows, the installation procedure is:
1. Install setuptools.
2. Install pyreadline. You can use the command pip install pyreadline from a terminal, or the
binary installer appropriate for your platform from the PyPI page.
3. Install IPython itself, which you can download from PyPI or from our site. Note that on Windows 7,
you must right-click and ‘Run as administrator’ for the Start menu shortcuts to be created.
IPython by default runs in a terminal window, but the normal terminal application supplied by Microsoft
Windows is very primitive. You may want to download the excellent and free Console application instead,
which is a far superior tool. You can even configure Console to give you by default an IPython tab, which is
very convenient to create new IPython sessions directly from the working terminal.
It is also possible to install the development version of IPython from our Git source code repository. To do
this you will need to have Git installed on your system. Then just do:
Some users want to be able to follow the development branch as it changes. If you have setuptools
installed, this is easy. Simply replace the last step by:
This creates links in the right places and installs the command line script to the appropriate places.
Then, if you want to update your IPython at any time, just do:
$ git pull
IPython now uses git submodules to ship its javascript dependencies. If you run IPython from git master,
you may need to update submodules once in a while with:
or
Another option is to copy git hooks to your ./git/hooks/ directory to ensure that your submodules are
up to date on each pull.
There are a number of basic optional dependencies that most users will want to get. These are:
• readline (for command line editing, tab completion, etc.)
• nose (to run the IPython test suite)
If you are comfortable installing these things yourself, have at it, otherwise read on for more details.
IPython uses several other modules, such as pexpect and path.py, if they are installed on your system, but it
can also use bundled versions from IPython.external, so there’s no need to install them separately.
readline
As indicated above, on Windows, to get full functionality in the console version of IPython, PyReadline is
needed. PyReadline is a separate, Windows only implementation of readline that uses native Windows calls
through ctypes. The easiest way of installing PyReadline is you use the binary installer available here.
On OSX, if you are using the built-in Python shipped by Apple, you will be missing a proper readline
implementation as Apple ships instead a library called libedit that provides only some of readline’s
functionality. While you may find libedit sufficient, we have occasional reports of bugs with it and several
developers who use OS X as their main environment consider libedit unacceptable for productive, regular
use with IPython.
Therefore, IPython on OS X depends on the gnureadline module. We will not consider comple-
tion/history problems to be bugs for IPython if you are using libedit.
To get a working readline module on OS X, just do (with pip installed):
Note: Other Python distributions on OS X (such as Anaconda, fink, MacPorts) already have proper readline
so you likely don’t have to do this step.
When IPython is installed with setuptools, (e.g. using the pip command), the correct readline should
be installed if you specify the terminal optional dependencies:
nose
To run the IPython test suite you will need the nose package. Nose provides a great way of sniffing out and
running all of the IPython tests. The simplest way of getting nose is to use pip:
$ iptest
IPython.parallel provides a nice architecture for parallel computing, with a focus on fluid interactive work-
flows. These features require just one package: PyZMQ. See the next section for PyZMQ details.
On a Unix style platform (including OS X), if you want to use setuptools, you can just do:
Security in IPython.parallel is provided by SSH tunnels. By default, Linux and OSX clients will use the
shell ssh command, but on Windows, we also support tunneling with paramiko.
pyzmq
IPython 0.11 introduced some new functionality, including a two-process execution model using ZeroMQ
for communication. The Python bindings to ZeroMQ are found in the PyZMQ project, which is pip install-
able. If you are on Python 2.7, 3.3, or 3.4 on OSX or Windows, pyzmq has eggs and wheels that include
ZeroMQ itself.
IPython.kernel.zmq depends on pyzmq >= 2.2.
pyzmq
Like the IPython.parallel package, the QT Console requires ZeroMQ and PyZMQ.
Qt
Also with 0.11, a new GUI was added using the work in IPython.kernel.zmq, which can be launched
with ipython qtconsole. The GUI is built on Qt, and works with either PyQt, or PySide.
pygments
The syntax-highlighting in ipython qtconsole is done with the pygments project, which is pip install-
able.
The IPython notebook is a notebook-style web interface to IPython and can be started with the command
ipython notebook.
pyzmq
Tornado
The IPython notebook uses the Tornado project for its HTTP server. Tornado 2.1 is required, in order to
support current versions of browsers, due to an update to the websocket protocol.
Jinja
The IPython notebook uses the Jinja templating tool to render HTML pages.
MathJax
The IPython notebook uses the MathJax Javascript library for rendering LaTeX in web browsers. Because
MathJax is large, we don’t include it with IPython. Normally IPython will load MathJax from a CDN, but
if you have a slow network connection, or want to use LaTeX without an internet connection at all, you can
install MathJax locally.
If you need tighter configuration control, you can download your own copy of MathJax from http://www.
mathjax.org/download/ - use the MathJax-2.0 link. When you have the file stored locally, install it with:
For unusual needs, IPython can tell you what directory it wants to find MathJax in:
By default Mathjax will be installed in your ipython profile directory, but you can make system wide install,
please refer to the documentation and helper function of IPython.external.mathjax
Browser Compatibility
pandoc
The most important dependency of nbconvert is Pandoc 1.10 or later, a document format translation program.
This is not a Python package, so it cannot be expressed as a regular IPython dependency with setuptools.
To install pandoc on Linux, you can generally use your package manager:
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Introducing IPython
You don’t need to know anything beyond Python to start using IPython – just type commands as you would
at the standard Python prompt. But IPython can do much more than the standard prompt. Some key features
are described here. For more information, check the tips page, or look at examples in the IPython cookbook.
If you’ve never used Python before, you might want to look at the official tutorial or an alternative, Dive into
Python.
The four most helpful commands, as well as their brief description, is shown to you in a banner, every time
you start IPython:
command description
? Introduction and overview of IPython’s features.
%quickref Quick reference.
help Python’s own help system.
object? Details about ‘object’, use ‘object??’ for extra details.
257
IPython Documentation, Release 3.0.0-dev
Tab completion
Tab completion, especially for attributes, is a convenient way to explore the structure of any object you’re
dealing with. Simply type object_name.<TAB> to view the object’s attributes (see the readline section
for more). Besides Python objects and keywords, tab completion also works on file and directory names.
Typing object_name? will print all sorts of details about any object, including docstrings, function defi-
nition lines (for call arguments) and constructor details for classes. To get specific information on an object,
you can use the magic commands %pdoc, %pdef, %psource and %pfile
Magic functions
IPython has a set of predefined ‘magic functions’ that you can call with a command line style syntax. There
are two kinds of magics, line-oriented and cell-oriented. Line magics are prefixed with the % character and
work much like OS command-line calls: they get as an argument the rest of the line, where arguments are
passed without parentheses or quotes. Cell magics are prefixed with a double %%, and they are functions
that get as an argument not only the rest of the line, but also the lines below it in a separate argument.
The following examples show how to call the builtin %timeit magic, both in line and cell mode:
run thescript.py
You can toggle this behavior by running the %automagic magic. Cell magics must always have the %%
prefix.
A more detailed explanation of the magic system can be obtained by calling %magic, and for more details
on any magic function, call %somemagic? to read its docstring. To see all the available magic functions,
call %lsmagic.
See also:
The %run magic command allows you to run any python script and load all of its data directly into the
interactive namespace. Since the file is re-read from disk each time, changes you make to it are reflected
immediately (unlike imported modules, which have to be specifically reloaded). IPython also includes
dreload, a recursive reload function.
%run has special flags for timing the execution of your scripts (-t), or for running them under the control of
either Python’s pdb debugger (-d) or profiler (-p).
The %edit command gives a reasonable approximation of multiline editing, by invoking your favorite
editor on the spot. IPython will execute the code you type in there as if it were typed interactively.
Debugging
After an exception occurs, you can call %debug to jump into the Python debugger (pdb) and examine the
problem. Alternatively, if you call %pdb, IPython will automatically start the debugger on any uncaught
exception. You can print variables, see code, execute statements and even walk up and down the call stack
to track down the true source of the problem. This can be an efficient way to develop and debug code, in
many cases eliminating the need for print statements or external debugging tools.
You can also step through a program from the beginning by calling %run -d theprogram.py.
History
IPython stores both the commands you enter, and the results it produces. You can easily go through previous
commands with the up- and down-arrow keys, or access your history in more sophisticated ways.
Input and output history are kept in variables called In and Out, keyed by the prompt numbers, e.g. In[4].
The last three objects in output history are also kept in variables named _, __ and ___.
You can use the %history magic function to examine past input and output. Input history from previous
sessions is saved in a database, and IPython can be configured to save output history.
Several other magic functions can use your input history, including %edit, %rerun, %recall, %macro,
%save and %pastebin. You can use a standard format to refer to lines:
This will take line 3 and lines 18 to 20 from the current session, and lines 1-5 from the previous session.
To run any command at the system shell, simply prefix it with !, e.g.:
!ping www.bbc.co.uk
You can capture the output into a Python list, e.g.: files = !ls. To pass the values of Python variables
or expressions to system commands, prefix them with $: !grep -rF $pattern ipython/*. See our
shell section for more details.
It’s convenient to have aliases to the system commands you use most often. This allows you to work
seamlessly from inside IPython with the same commands you are used to in your system shell. IPython
comes with some pre-defined aliases and a complete system for changing directories, both via a stack (see
%pushd, %popd and %dhist) and via direct %cd. The latter keeps a history of visited directories and
allows you to go to any previously visited one.
Configuration
Much of IPython can be tweaked through configuration. To get started, use the command ipython
profile create to produce the default config files. These will be placed in ~/.ipython/
profile_default, and contain comments explaining what the various options do.
Profiles allow you to use IPython for different tasks, keeping separate config files and history for each one.
More details in the profiles section.
Startup Files
If you want some code to be run at the beginning of every IPython session, the easiest way is to add
Python (.py) or IPython (.ipy) scripts to your profile_default/startup/ directory. Files here will
be executed as soon as the IPython shell is constructed, before any other code or scripts you have spec-
ified. The files will be run in order of their names, so you can control the ordering with prefixes, like
10-myimports.py.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
The IPython cookbook details more things you can do with IPython.
A few lines of code are enough to load a complete IPython inside your own programs, giving you the ability
to work with your data interactively after automatic processing has been completed. See the embedding
section.
Run doctests
Run your doctests from within IPython for development and debugging. The special %doctest_mode com-
mand toggles a mode where the prompt, output and exceptions display matches as closely as possible that
of the default Python interpreter. In addition, this mode allows you to directly paste in code that contains
leading ‘>>>’ prompts, even if they have extra leading whitespace (as is common in doctest files). This
combined with the %history -t call to see your translated history allows for an easy doctest workflow,
where you can go from doctest to interactive execution to pasting into valid Python code as needed.
Use the IPython.lib.demo.Demo class to load any Python script as an interactive demo. With a
minimal amount of simple markup, you can control the execution of the script, stopping as needed. See here
for more.
Suppress output
Put a ‘;’ at the end of a line to suppress the printing of output. This is useful when doing calculations which
generate long output you are not interested in seeing. It also keeps the object out of the output cache, so if
you’re working with large temporary objects, they’ll be released from memory sooner.
When you call %edit with no arguments, IPython opens an empty editor with a temporary file, and it returns
the contents of your editing session as a string variable. Thanks to IPython’s output caching mechanism,
this is automatically stored:
In [1]: %edit
Now, if you call %edit -p, IPython tries to open an editor with the same data as the last time you used
%edit. So if you haven’t used %edit in the meantime, this same contents will reopen; however, it will be
done in a new file. This means that if you make changes and you later want to find an old version, you
can always retrieve it by using its output number, via ‘%edit _NN’, where NN is the number of the output
prompt.
Continuing with the example above, this should illustrate this idea:
In [2]: edit -p
In [3]: edit _1
This section was written after a contribution by Alexander Belchenko on the IPython user list.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
IPython reference
Command-line usage
If invoked with no options, it executes all the files listed in sequence and drops you into the interpreter while
still acknowledging any options you may have set in your ipython_config.py. This behavior is different from
standard Python, which when called as python -i will only execute one file and ignore your configuration
setup.
Please note that some of the configuration options are not available at the command line, simply be-
cause they are not practical here. Look into your configuration files for details on those. There
are separate configuration files for each profile, and the files look like ipython_config.py or
ipython_config_frontendname.py. Profile directories look like profile_profilename and
are typically installed in the IPYTHONDIR directory, which defaults to $HOME/.ipython. For Windows
users, HOME resolves to C:\Users\YourUserName in most instances.
Command-line Options
To see the options IPython accepts, use ipython --help (and you probably should run the output
through a pager such as ipython --help | less for more convenient reading). This shows all the
options that have a single-word alias to control them, but IPython lets you configure all of its objects from the
command-line by passing the full class name and a corresponding value; type ipython --help-all to
see this full list. For example:
ipython --matplotlib qt
is equivalent to:
ipython --TerminalIPythonApp.matplotlib='qt'
Note that in the second form, you must use the equal sign, as the expression is evaluated as an actual Python
assignment. While in the above example the short form is more convenient, only the most common options
have a short form, while any configurable variable in IPython can be set at the command-line by using the
long form. This long form is the same syntax used in the configuration files, if you want to set these options
permanently.
Interactive use
IPython is meant to work as a drop-in replacement for the standard interactive interpreter. As such, any
code which is valid python should execute normally under IPython (cases where this is not true should be
reported as bugs). It does, however, offer many features which are not available at a standard python prompt.
What follows is a list of these.
Windows, unfortunately, uses the ‘\’ character as a path separator. This is a terrible choice, because ‘\’ also
represents the escape character in most modern programming languages, including Python. For this reason,
using ‘/’ character is recommended if you have problems with \. However, in Windows commands ‘/’ flags
options, so you can not use it for the root directory. This means that paths beginning at the root must be
typed in a contrived manner like: %copy \opt/foo/bar.txt \tmp
IPython will treat any line whose first character is a % as a special call to a ‘magic’ function. These allow
you to control the behavior of IPython itself, plus a lot of system-type features. They are all prefixed with a
% character, but parameters are given without parentheses or quotes.
Lines that begin with %% signal a cell magic: they take as arguments not only the rest of the current line,
but all lines below them as well, in the current execution block. Cell magics can in fact make arbitrary
modifications to the input they receive, which need not even be valid Python code at all. They receive the
whole block as a single string.
As a line magic example, the %cd magic works just like the OS command of the same name:
In [8]: %cd
/home/fperez
In this case, x = range(10000) is called as the line argument, and the block with min(x) and max(x)
is called as the cell body. The %timeit magic receives both.
If you have ‘automagic’ enabled (as it by default), you don’t need to type in the single % explicitly for line
magics; IPython will scan its internal list of magic functions and call one if it exists. With automagic on you
can then just type cd mydir to go to directory ‘mydir’:
In [9]: cd mydir
/home/fperez/mydir
Note that cell magics always require an explicit %% prefix, automagic calling only works for line magics.
The automagic system has the lowest possible precedence in name searches, so you can freely use variables
with the same names as magic commands. If a magic command is ‘shadowed’ by a variable, you will need
the explicit % prefix to use it:
In [6]: cd ipython
/home/fperez/ipython
Type %magic for more information, including a list of all available magic functions at any time and their
docstrings. You can also type %magic_function_name? (see below for information on the ‘?’ system)
to get information about any particular magic function you are interested in.
The API documentation for the IPython.core.magic module contains the full docstrings of all cur-
rently available magic commands.
See also:
Built-in magic commands A list of the line and cell magics available in IPython by default
Defining custom magics How to define and register additional magic functions
Simply type help() to access Python’s standard help system. You can also type help(object) for
information about a given object, or help('keyword') for information on a keyword. You may need to
configure your PYTHONDOCS environment variable for this feature to work correctly.
Typing ?word or word? prints detailed information about an object. If certain strings in the object are too
long (e.g. function signatures) they get snipped in the center for brevity. This system gives access variable
types and values, docstrings, function prototypes and other useful information.
If the information will not fit in the terminal, it is displayed in a pager (less if available, otherwise a basic
internal pager).
Typing ??word or word?? gives access to the full information, including the source code where possible.
Long strings are not snipped.
The following magic functions are particularly useful for gathering information about your working envi-
ronment:
• %pdoc <object>: Print (or run through a pager if too long) the docstring for an object. If the given
object is a class, it will print both the class and the constructor docstrings.
• %pdef <object>: Print the call signature for any callable object. If the object is a class, print the
constructor information.
• %psource <object>: Print (or run through a pager if too long) the source code for an object.
• %pfile <object>: Show the entire source file where an object was defined via a pager, opening it at
the line where the object definition begins.
• %who/%whos: These functions give information about identifiers you have defined interactively (not
things you loaded or defined in your configuration files). %who just prints a list of identifiers and
%whos prints a table with some basic details about each identifier.
Note that the dynamic object information functions (?/??, %pdoc, %pfile, %pdef, %psource) work
on object attributes, as well as directly on variables. For example, after doing import os, you can use
os.path.abspath??.
Readline-based features
These features require the GNU readline library, so they won’t work if your Python installation lacks readline
support. We will first describe the default behavior IPython uses, and then how to change it to suit your
preferences.
At any time, hitting TAB will complete any available python commands or variable names, and show you a
list of the possible completions if there’s no unambiguous one. It will also complete filenames in the current
directory if no python names match what you’ve typed so far.
IPython provides two ways for searching through previous input and thus reduce the need for repetitive
typing:
1. Start typing, and then use the up and down arrow keys (or Ctrl-p and Ctrl-n) to search through
only the history items that match what you’ve typed so far.
2. Hit Ctrl-r: to open a search prompt. Begin typing and the system searches your history for lines
that contain what you’ve typed so far, completing as much as it can.
IPython will save your input history when it leaves and reload it next time you restart it. By default, the
history file is named .ipython/profile_name/history.sqlite.
Autoindent
IPython can recognize lines ending in ‘:’ and indent the next line, while also un-indenting automatically
after ‘raise’ or ‘return’.
This feature uses the readline library, so it will honor your ~/.inputrc configuration (or whatever file
your INPUTRC environment variable points to). Adding the following lines to your .inputrc file can
make indenting/unindenting more convenient (M-i indents, M-u unindents):
# if you don't already have a ~/.inputrc file, you need this include:
$include /etc/inputrc
$if Python
"\M-i": " "
"\M-u": "\d\d\d\d"
$endif
Note that there are 4 spaces between the quote marks after “M-i” above.
Warning: Setting the above indents will cause problems with unicode text entry in the terminal.
Warning: Autoindent is ON by default, but it can cause problems with the pasting of multi-line indented
code (the pasted code gets re-indented on each line). A magic function %autoindent allows you to toggle
it on/off at runtime. You can also disable it permanently on in your ipython_config.py file (set
TerminalInteractiveShell.autoindent=False).
If you want to paste multiple lines in the terminal, it is recommended that you use %paste.
All these features are based on the GNU readline library, which has an extremely customizable interface.
Normally, readline is configured via a .inputrc file. IPython respects this, and you can also customise
readline by setting the following configuration options:
• InteractiveShell.readline_parse_and_bind: this holds a list of strings to be executed
via a readline.parse_and_bind() command. The syntax for valid commands of this kind can be found
by reading the documentation for the GNU readline library, as these commands are of the kind which
readline accepts in its configuration file.
• InteractiveShell.readline_remove_delims: a string of characters to be removed from
the default word-delimiters list used by readline, so that completions may be performed on strings
which contain them. Do not change the default value unless you know what you’re doing.
You will find the default values in your configuration file.
You can log all input from a session either by starting IPython with the command line switch
--logfile=foo.py (see here) or by activating the logging at any moment with the magic function
%logstart.
Log files can later be reloaded by running them as scripts and IPython will attempt to ‘replay’ the log by
executing all the lines in it, thus restoring the state of a previous session. This feature is not quite perfect,
but can still be useful in many cases.
The log files can also be used as a way to have a permanent record of any code you wrote while experiment-
ing. Log files are regular text files which you can later open in your favorite text editor to extract code or to
‘clean them up’ before using them to replay a session.
The %logstart function for activating logging in mid-session is used as follows:
%logstart [log_name [log_mode]]
If no name is given, it defaults to a file named ‘ipython_log.py’ in your current working directory, in ‘rotate’
mode (see below).
‘%logstart name’ saves to file ‘name’ in ‘backup’ mode. It saves your history up to that point and then
continues logging.
%logstart takes a second optional parameter: logging mode. This can be one of (note that the modes are
given unquoted):
Any input line beginning with a ! character is passed verbatim (minus the !, of course) to the underlying
operating system. For example, typing !ls will run ‘ls’ in the current directory.
You can assign the result of a system command to a Python variable with the syntax myfiles = !ls.
This gets machine readable output from stdout (e.g. without colours), and splits on newlines. To explicitly
get this sort of output without assigning to a variable, use two exclamation marks (!!ls) or the %sx magic
command.
The captured list has some convenience features. myfiles.n or myfiles.s returns a string delimited
by newlines or spaces, respectively. myfiles.p produces path objects from the list items. See String lists
for details.
IPython also allows you to expand the value of python variables when making system calls. Wrap variables
or expressions in {braces}:
The %alias magic function allows you to define magic functions which are in fact system shell commands.
These aliases can have parameters.
%alias alias_name cmd defines ‘alias_name’ as an alias for ‘cmd’
Then, typing alias_name params will execute the system command ‘cmd params’ (from your under-
lying operating system).
You can also define aliases with parameters using %s specifiers (one per parameter). The following example
defines the parts function as an alias to the command ‘echo first %s second %s’ where each %s will be
replaced by a positional parameter to the call to %parts:
If called with no parameters, %alias prints the table of currently defined aliases.
The %rehashx magic allows you to load your entire $PATH as ipython aliases. See its docstring for further
details.
Recursive reload
The IPython.lib.deepreload module allows you to recursively reload a module: changes made to
any of its dependencies will be reloaded without having to exit. To start using it, do:
IPython provides the option to see very detailed exception tracebacks, which can be especially useful when
debugging large programs. You can run any Python file with the %run function to benefit from these detailed
tracebacks. Furthermore, both normal and verbose tracebacks can be colored (if your terminal supports it)
which makes them much easier to parse visually.
See the magic %xmode and %colors functions for details.
These features are basically a terminal version of Ka-Ping Yee’s cgitb module, now part of the standard
Python library.
IPython offers numbered prompts (In/Out) with input and output caching (also referred to as ‘input history’).
All input is saved and can be retrieved as variables (besides the usual arrow key recall), in addition to the
%rep magic command that brings a history entry up for editing on the next command line.
For output that is returned from actions, a system similar to the input cache exists but using _ instead of
_i. Only actions that produce a result (NOT assignments, for example) are cached. If you are familiar with
Mathematica, IPython’s _ variables behave exactly like Mathematica’s % variables.
The following variables always exist:
• [_] (a single underscore): stores previous output, like Python’s default interpreter.
• [__] (two underscores): next previous.
• [___] (three underscores): next-next previous.
Additionally, global variables named _<n> are dynamically created (<n> being the prompt counter), such
that the result of output <n> is always available as _<n> (don’t use the angle brackets, just the number, e.g.
_21).
These variables are also stored in a global dictionary (not a list, since it only has entries for lines which
returned a result) available under the names _oh and Out (similar to _ih and In). So the output from line 12
can be obtained as _12, Out[12] or _oh[12]. If you accidentally overwrite the Out variable you can
recover it by typing Out=_oh at the prompt.
This system obviously can potentially put heavy memory demands on your system, since it prevents Python’s
garbage collector from removing any previously computed results. You can control how many results are
kept in memory with the configuration option InteractiveShell.cache_size. If you set it to 0,
output caching is disabled. You can also use the %reset and %xdel magics to clear large items from
memory.
Directory history
Your history of visited directories is kept in the global list _dh, and the magic %cd command can be used
to go to any entry in that list. The %dhist command allows you to view this history. Do cd -<TAB> to
conveniently view the directory history.
These features were adapted from Nathan Gray’s LazyPython. They are meant to allow less typing for
common situations.
Callable objects (i.e. functions, methods, etc) can be invoked like this (notice the commas between the
arguments):
Note: This feature is disabled by default. To enable it, use the %autocall magic command. The
commands below with special prefixes will always work, however.
You can force automatic parentheses by using ‘/’ as the first character of a line. For example:
Note that the ‘/’ MUST be the first character on the line! This won’t work:
In most cases the automatic algorithm should work, so you should rarely need to explicitly invoke /. One
notable exception is if you are trying to call a function with a list of tuples as arguments (the parenthesis
will confuse IPython):
IPython tells you that it has altered your command line by displaying the new command line preceded by
--->.
You can force automatic quoting of a function’s arguments by using , or ; as the first character of a line.
For example:
If you use ‘;’ the whole argument is quoted as a single string, while ‘,’ splits on whitespace:
Note that the ‘,’ or ‘;’ MUST be the first character on the line! This won’t work:
Python honors the environment variable PYTHONSTARTUP and will execute at startup the file referenced
by this variable. If you put the following code at the end of that file, then IPython will be your working
environment anytime you start Python:
The raise SystemExit is needed to exit Python when it finishes, otherwise you’ll be back at the normal
Python >>> prompt.
This is probably useful to developers who manage multiple Python versions and don’t want to have corre-
spondingly multiple IPython versions. Note that in this mode, there is no way to pass IPython any command-
line options, as those are trapped first by Python itself.
Embedding IPython
import IPython
IPython.start_ipython(argv=[])
at any point in your program. This will load IPython configuration, startup files, and everything, just as if it
were a normal IPython session.
It is also possible to embed an IPython shell in a namespace in your Python code. This allows you to evaluate
dynamically the state of your code, operate with your variables, analyze them, etc. Note however that any
changes you make to values while in the shell do not propagate back to the running code, so it is safe to
modify your values because you won’t break your code in bizarre ways by doing so.
Note: At present, embedding IPython cannot be done from inside IPython. Run the code samples below
outside IPython.
This feature allows you to easily have a fully functional python environment for doing object introspection
anywhere in your code with a simple function call. In some cases a simple print statement is enough, but if
you need to do more detailed analysis of a code fragment this feature can be very valuable.
It can also be useful in scientific computing situations where it is common to need to do some automatic,
computationally intensive part and then stop to look at data, plots, etc. Opening an IPython instance will
give you full access to your data and functions, and you can resume program execution once you are done
with the interactive part (perhaps to stop again later, as many times as needed).
The following code snippet is the bare minimum you need to include in your Python programs for this to
work (detailed examples follow later):
from IPython import embed
You can also embed an IPython kernel, for use with qtconsole, etc. via IPython.embed_kernel().
This should function work the same way, but you can connect an external frontend (ipython
qtconsole or ipython console), rather than interacting with it in the terminal.
You can run embedded instances even in code which is itself being run at the IPython interactive prompt
with ‘%run <filename>’. Since it’s easy to get lost as to where you are (in your top-level IPython or in
your embedded one), it’s a good idea in such cases to set the in/out prompts to something different for the
embedded instances. The code examples below illustrate this.
You can also have multiple IPython instances in your program and open them separately, for example with
different options for data presentation. If you close and open the same instance multiple times, its prompt
counters simply continue from each execution to the next.
Please look at the docstrings in the embed module for more details on the use of this system.
The following sample file illustrating how to use the embedding functionality is provided in the examples
directory as embed_class_long.py. It should be fairly self-explanatory:
#!/usr/bin/env python
"""An example of how to embed an IPython shell into a running program.
Please see the documentation in the IPython.Shell module for more details.
# IPython injects get_ipython into builtins, so you can know if you have
˓→nested
# copies running.
# Try running this code both at the command line and from inside IPython (with
# %run example-embed.py)
# You can then call ipshell() anywhere you need it (with an optional
# message):
ipshell('***Called from top level. '
'Hit Ctrl-D to exit interpreter and continue program.\n'
'Note that if you use %kill_embedded, you can fully deactivate\n'
'This embedded instance so it will never turn on again')
#---------------------------------------------------------------------------
# More details:
# - A call-specific header string, which you can use to indicate where in the
# execution flow the shell is starting.
# Both the startup banner and the exit message default to None, and can be set
# either at the instance constructor or at any other time with the
# by setting the banner and exit_msg attributes.
# The shell instance can be also put in 'dummy' mode globally or on a per-call
# basis. This gives you fine control for debugging without having to change
# code all over the place.
# This is how the global banner and exit_msg can be reset at any point
ipshell.banner = 'Entering interpreter - New Banner'
ipshell.exit_msg = 'Leaving interpreter - New exit_msg'
def foo(m):
s = 'spam'
ipshell('***In foo(). Try %whos, or print s or m:')
print('foo says m = ',m)
def bar(n):
s = 'eggs'
ipshell('***In bar(). Try %whos, or print s or n:')
print('bar says n = ',n)
# The shell can be put in 'dummy' mode where calls to it silently return. This
# allows you, for example, to globally turn off debugging for a program with a
# single call.
ipshell.dummy_mode = True
print('\nTrying to call IPython which is now "dummy":')
ipshell()
print('Nothing happened...')
# The global 'dummy' mode can still be overridden for a single call
print('\nOverriding dummy mode manually:')
ipshell(dummy=False)
Once you understand how the system functions, you can use the following code fragments in your programs
which are ready for cut and paste:
"""Quick code snippets for embedding IPython into other programs.
See embed_class_long.py for full details, this file has the bare minimum code
˓→for
cut and paste use once you understand how to use the system."""
#---------------------------------------------------------------------------
# This code loads IPython but modifies a few things if it detects it's running
# embedded in another IPython session (helps avoid confusion)
try:
get_ipython
except NameError:
banner=exit_msg=''
else:
banner = '*** Nested interpreter ***'
exit_msg = '*** Back in main IPython ***'
#---------------------------------------------------------------------------
# This code will load an embeddable IPython shell always with no changes for
# nested embededings.
#---------------------------------------------------------------------------
# This code loads an embeddable shell only if NOT running inside
# IPython. Inside IPython, the embeddable shell variable ipshell is just a
# dummy function.
try:
get_ipython
except NameError:
from IPython.terminal.embed import InteractiveShellEmbed
ipshell = InteractiveShellEmbed()
# Now ipshell() will open IPython anywhere in the code
else:
# Define a dummy ipshell() so the same code doesn't crash inside an
# interactive IPython
def ipshell(): pass
pdb, the Python debugger, is a powerful interactive debugger which allows you to step through code, set
breakpoints, watch variables, etc. IPython makes it very easy to start any script under the control of pdb,
regardless of whether you have wrapped it into a ‘main()’ function or not. For this, simply type %run -d
myscript at an IPython prompt. See the %run command’s documentation for more details, including
how to control where pdb will stop execution first.
For more information on the use of the pdb debugger, see Debugger Commands in the Python documenta-
tion.
Post-mortem debugging
Going into a debugger when an exception occurs can be extremely useful in order to find the origin of subtle
bugs, because pdb opens up at the point in your code which triggered the exception, and while your program
is at this point ‘dead’, all the data is still available and you can walk up and down the stack frame and
understand the origin of the problem.
You can use the %debug magic after an exception has occurred to start post-mortem debugging. IPython
can also call debugger every time your code triggers an uncaught exception. This feature can be toggled
with the %pdb magic command, or you can start IPython with the --pdb option.
For a post-mortem debugger in your programs outside IPython, put the following lines toward the top of
your ‘main’ routine:
import sys
from IPython.core import ultratb
sys.excepthook = ultratb.FormattedTB(mode='Verbose',
color_scheme='Linux', call_pdb=1)
The mode keyword can be either ‘Verbose’ or ‘Plain’, giving either very detailed or normal tracebacks
respectively. The color_scheme keyword can be one of ‘NoColor’, ‘Linux’ (default) or ‘LightBG’. These
are the same options which can be set in IPython with --colors and --xmode.
This will give any of your programs detailed, colored tracebacks with automatic invocation of pdb.
IPython is smart enough to filter out input prompts, be they plain Python ones (>>> and ...) or IPython
ones (In [N]: and ...:). You can therefore copy and paste from existing interactive sessions without
worry.
The following is a ‘screenshot’ of how things work, copying an example from the standard Python tutorial:
In [3]: ... a, b = 0, 1
In [2]: f(3)
Out[2]: 9
%gui [GUINAME]
With no arguments, %gui removes all GUI support. Valid GUINAME arguments are wx, qt, gtk and tk.
Thus, to use wxPython interactively and create a running wx.App object, do:
%gui wx
You can also start IPython with an event loop set up using the --gui flag:
$ ipython --gui=qt
For information on IPython’s matplotlib integration (and the matplotlib mode) see this section.
For developers that want to use IPython’s GUI event loop integration in the form of a library, these capabili-
ties are exposed in library form in the IPython.lib.inputhook and IPython.lib.guisupport
modules. Interested developers should see the module docstrings for more information, but there are a few
points that should be mentioned here.
First, the PyOSInputHook approach only works in command line settings where readline is activated.
The integration with various eventloops is handled somewhat differently (and more simply) when using the
standalone kernel, as in the qtconsole and notebook.
Second, when using the PyOSInputHook approach, a GUI application should not start its event loop.
Instead all of this is handled by the PyOSInputHook. This means that applications that are meant to be
used both in IPython and as standalone apps need to have special code to detects how the application is
being run. We highly recommend using IPython’s support for this. Since the details vary slightly between
toolkits, we point you to the various examples in our source directory examples/lib that demonstrate
these capabilities.
Third, unlike previous versions of IPython, we no longer “hijack” (replace them with no-ops) the event
loops. This is done to allow applications that actually need to run the real event loops to do so. This is often
needed to process pending events at critical points.
Finally, we also have a number of examples in our source directory examples/lib that demonstrate these
capabilities.
When you use --gui=qt or --matplotlib=qt, IPython can work with either PyQt4 or PySide. There
are three options for configuration here, because PyQt4 has two APIs for QString and QVariant - v1, which
is the default on Python 2, and the more natural v2, which is the only API supported by PySide. v2 is also
the default for PyQt4 on Python 3. IPython’s code for the QtConsole uses v2, but you can still use any
interface in your code, since the Qt frontend is in a different process.
The default will be to import PyQt4 without configuration of the APIs, thus matching what most applications
would expect. It will fall back of PySide if PyQt4 is unavailable.
If specified, IPython will respect the environment variable QT_API used by ETS. ETS 4.0 also works with
both PyQt4 and PySide, but it requires PyQt4 to use its v2 API. So if QT_API=pyside PySide will be
used, and if QT_API=pyqt then PyQt4 will be used with the v2 API for QString and QVariant, so ETS
codes like MayaVi will also work with IPython.
If you launch IPython in matplotlib mode with ipython --matplotlib=qt, then IPython will ask
matplotlib which Qt library to use (only if QT_API is not set), via the ‘backend.qt4’ rcParam. If matplotlib
is version 1.0.1 or older, then IPython will always use PyQt4 without setting the v2 APIs, since neither v2
PyQt nor PySide work.
Warning: Note that this means for ETS 4 to work with PyQt4, QT_API must be set to work with
IPython’s qt integration, because otherwise PyQt4 will be loaded in an incompatible mode.
It also means that you must not have QT_API set if you want to use --gui=qt with code that requires
PyQt4 API v1.
matplotlib provides high quality 2D and 3D plotting for Python. matplotlib can produce plots on screen
using a variety of GUI toolkits, including Tk, PyGTK, PyQt4 and wxPython. It also provides a number
of commands useful for scientific computing, all with a syntax compatible with that of the popular Matlab
program.
To start IPython with matplotlib support, use the --matplotlib switch. If IPython is already running,
you can run the %matplotlib magic. If no arguments are given, IPython will automatically detect your
choice of matplotlib backend. You can also request a specific backend with %matplotlib backend,
where backend must be one of: ‘tk’, ‘qt’, ‘wx’, ‘gtk’, ‘osx’. In the web notebook and Qt console, ‘inline’
is also a valid backend value, which produces static figures inlined inside the application window instead of
matplotlib’s interactive figures that live in separate windows.
IPython ships with a basic system for running scripts interactively in sections, useful when presenting code
to audiences. A few tags embedded in comments (so that the script remains valid Python code) divide a
file into separate blocks, and the demo can be run one block at a time, with IPython printing (with syntax
highlighting) the block before executing it, and returning to the interactive prompt after each block. The
interactive namespace is updated after each block is run with the contents of the demo’s namespace.
This allows you to show a piece of code, run it and then execute interactively commands based on the
variables just created. Once you want to continue, you simply execute the next block of the demo. The
following listing shows the markup necessary for dividing a script into sections for execution as a demo:
Any python script can be run as a demo, but that does little more than showing
it on-screen, syntax-highlighted in one shot. If you add a little simple
markup, you can stop at specified intervals and return to the ipython prompt,
resuming execution later.
# The mark below defines a block boundary, which is a point where IPython will
# stop execution and return to the interactive prompt.
# <demo> --- stop ---
x = 1
y = 2
print('z=',x)
print('bye!')
In order to run a file as a demo, you must first make a Demo object out of it. If the file is named myscript.py,
the following code will make a demo:
mydemo = Demo('myscript.py')
This creates the mydemo object, whose blocks you run one at a time by simply calling the object with no
arguments. Then call it to run each step of the demo:
mydemo()
Demo objects can be restarted, you can move forward or back skipping blocks, re-execute the last block,
etc. See the IPython.lib.demo module and the Demo class for details.
Limitations: These demos are limited to fairly simple uses. In particular, you cannot break up sections
within indented code (loops, if statements, function definitions, etc.) Supporting something like this would
basically require tracking the internal execution state of the Python interpreter, so only top-level divisions
are allowed. If you want to be able to open an IPython instance at an arbitrary point in a program, you can
use IPython’s embedding facilities.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Overview
It is possible to adapt IPython for system shell usage. In the past, IPython shipped a special ‘sh’ profile for
this purpose, but it had been quarantined since 0.11 release, and in 1.0 it was removed altogether. Neverthe-
less, much of this section relies on machinery which does not require a custom profile.
You can set up your own ‘sh’ profile to be different from the default profile such that:
• Prompt shows the current directory (see Prompt customization)
• Make system commands directly available (in alias table) by running the %rehashx magic. If you
install new programs along your PATH, you might want to run %rehashx to update the alias table
• turn %autocall to full mode
Aliases
Once you run %rehashx, all of your $PATH has been loaded as IPython aliases, so you should be able to
type any normal system command and have it executed. See %alias? and %unalias? for details on the
alias facilities. See also %rehashx? for details on the mechanism used to load $PATH.
Directory management
Since each command passed by ipython to the underlying system is executed in a subshell which exits
immediately, you can NOT use !cd to navigate the filesystem.
IPython provides its own builtin %cd magic command to move in the filesystem (the % is not required
with automagic on). It also maintains a list of visited directories (use %dhist to see it) and allows direct
switching to any of them. Type cd? for more details.
%pushd, %popd and %dirs are provided for directory stack handling.
Prompt customization
Here are some prompt configurations you can try out interactively by using the %config magic:
You can change the prompt configuration to your liking permanently by editing ipython_config.py:
c.PromptManager.in_template = r'{color.LightGreen}\u@\h{color.LightBlue}[
˓→{color.LightCyan}\Y1{color.LightBlue}]{color.Green}|\#> '
c.PromptManager.in2_template = r'{color.Green}|{color.LightGreen}\D{color.
˓→Green}> '
c.PromptManager.out_template = r'<\#> '
Read more about the configuration system for details on how to find ipython_config.py.
String lists
String lists (IPython.utils.text.SList) are handy way to process output from system commands. They are
produced by var = !cmd syntax.
First, we acquire the output of ‘ls -l’:
Now, let’s take a look at the contents of ‘lines’ (the first number is the list element number):
[Q:doc/examples]|3> lines
<3> SList (.p, .n, .l, .s, .grep(), .fields() available).
˓→Value:
0: total 23
1: -rw-rw-rw- 1 ville None 1163 Sep 30 2006 example-demo.py
2: -rw-rw-rw- 1 ville None 1927 Sep 30 2006 example-embed-short.py
3: -rwxrwxrwx 1 ville None 4606 Sep 1 17:15 example-embed.py
4: -rwxrwxrwx 1 ville None 1017 Sep 30 2006 example-gnuplot.py
[Q:doc/examples]|4> l2 = lines.grep('embed',prune=1)
[Q:doc/examples]|5> l2
<5> SList (.p, .n, .l, .s, .grep(), .fields() available).
˓→Value:
0: total 23
1: -rw-rw-rw- 1 ville None 1163 Sep 30 2006 example-demo.py
2: -rwxrwxrwx 1 ville None 1017 Sep 30 2006 example-gnuplot.py
3: -rwxrwxrwx 1 ville None 339 Jun 11 18:01 extension.py
4: -rwxrwxrwx 1 ville None 113 Dec 20 2006 seteditor.py
5: -rwxrwxrwx 1 ville None 245 Dec 12 2006 seteditor.pyc
[Q:doc/examples]|6> l2.fields(8,0)
<6> SList (.p, .n, .l, .s, .grep(), .fields() available).
˓→Value:
0: total
1: example-demo.py -rw-rw-rw-
2: example-gnuplot.py -rwxrwxrwx
3: extension.py -rwxrwxrwx
4: seteditor.py -rwxrwxrwx
5: seteditor.pyc -rwxrwxrwx
Note how the line with ‘total’ does not raise IndexError.
If you want to split these (yielding lists), call fields() without arguments:
[Q:doc/examples]|7> _.fields()
<7>
[['total'],
['example-demo.py', '-rw-rw-rw-'],
['example-gnuplot.py', '-rwxrwxrwx'],
['extension.py', '-rwxrwxrwx'],
['seteditor.py', '-rwxrwxrwx'],
['seteditor.pyc', '-rwxrwxrwx']]
If you want to pass these separated with spaces to a command (typical for lists if files), use the .s property:
SLists are inherited from normal python lists, so every list method is available:
[Q:doc/examples]|21> lines.append('hey')
The .s property returns one string where lines are separated by single space (for convenient passing to
system commands). The .n property return one string where the lines are separated by a newline (i.e. the
original output of the function). If the items in string list are file names, .p can be used to get a list of “path”
objects for convenient file manipulation.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
We now have a version of IPython, using the new two-process ZeroMQ Kernel, running in a PyQt GUI.
This is a very lightweight widget that largely feels like a terminal, but provides a number of enhancements
only possible in a GUI, such as inline figures, proper multiline editing with syntax highlighting, graphical
calltips, and much more.
To get acquainted with the Qt console, type %guiref to see a quick introduction of its main features.
The Qt frontend has hand-coded emacs-style bindings for text navigation. This is not yet configurable.
Tip: Since the Qt console tries hard to behave like a terminal, by default it immediately executes single
lines of input that are complete. If you want to force multiline input, hit Ctrl-Enter at the end of the
first line instead of Enter, and it will open a new line for input. At any point in a multiline block, you can
force its execution (without having to go to the bottom) with Shift-Enter.
%load
The new %load magic (previously %loadpy) takes any script, and pastes its contents as your next input,
so you can edit it before executing. The script may be on your machine, but you can also specify an history
range, or a url, and it will download the script from the web. This is particularly useful for playing with
examples from documentation, such as matplotlib.
The %load magic can also load source code from objects in the user or global namespace by invoking the
-n option.
Inline Matplotlib
One of the most exciting features of the QtConsole is embedded matplotlib figures. You can use any standard
matplotlib GUI backend to draw the figures, and since there is now a two-process model, there is no longer
Fig. 4.1: The Qt console for IPython, using inline matplotlib plots.
display()
IPython provides a function display() for displaying rich representations of objects if they are available.
The IPython display system provides a mechanism for specifying PNG or SVG (and more) representa-
tions of objects for GUI frontends. When you enable matplotlib integration via the %matplotlib magic,
IPython registers convenient PNG and SVG renderers for matplotlib figures, so you can embed them in your
document by calling display() on one or more of them. This is especially useful for saving your work.
If you have a reference to a matplotlib figure object, you can always display that specific figure:
In [1]: f = plt.figure()
In [2]: plt.plot(np.rand(100))
Out[2]: [<matplotlib.lines.Line2D at 0x7fc6ac03dd90>]
In [3]: display(f)
In [5]: display(f)
--matplotlib inline
If you want to have all of your figures embedded in your session, instead of calling display(), you can
specify --matplotlib inline when you start the console, and each time you make a plot, it will show
up in your document, as if you had called display(fig)().
The inline backend can use either SVG or PNG figures (PNG being the default). It also supports the
special key 'retina', which is 2x PNG for high-DPI displays. To switch between them, set the
InlineBackend.figure_format configurable in a config file, or via the %config magic:
In [10]: %config InlineBackend.figure_format = 'svg'
Note: Changing the inline figure format also affects calls to display() above, even if you are not using
the inline backend for all figures.
By default, IPython closes all figures at the completion of each execution. This means you don’t have to
manually close figures, which is less convenient when figures aren’t attached to windows with an obvious
close button. It also means that the first matplotlib call in each cell will always create a new figure:
In [11]: plt.plot(range(100))
<single-line plot>
In [12]: plt.plot([1,3,2])
<another single-line plot>
However, it does prevent the list of active figures surviving from one input cell to the next, so if you want to
continue working with a figure, you must hold on to a reference to it:
In [11]: fig = gcf()
....: fig.plot(rand(100))
<plot>
In [12]: fig.title('Random Title')
<redraw plot with title>
IPythonQt has the ability to save your current session, as either HTML or XHTML. If you have been using
display() or inline matplotlib, your figures will be PNG in HTML, or inlined as SVG in XHTML. PNG
images have the option to be either in an external folder, as in many browsers’ “Webpage, Complete” option,
or inlined as well, for a larger, but more portable file.
Note: Export to SVG+XHTML requires that you are using SVG figures, which is not the default. To switch
the inline figure format to use SVG during an active session, do:
Or, you can add the same line (c.Inline... instead of %config Inline...) to your config files.
This will only affect figures plotted after making this call
The widget also exposes the ability to print directly, via the default print shortcut or context menu.
Note: Saving is only available to richtext Qt widgets, which are used by default, but if you pass the
--plain flag, saving will not be available to you.
See these examples of png/html and svg/xhtml output. Note that syntax highlighting does not survive
export. This is a known issue, and is being investigated.
Terminal IPython has always had some coloring, but never syntax highlighting. There are a few simple color
choices, specified by the colors flag or %colors magic:
• LightBG for light backgrounds
• Linux for dark backgrounds
• NoColor for a simple colorless terminal
The Qt widget has full support for the colors flag used in the terminal shell.
The Qt widget, however, has full syntax highlighting as you type, handled by the pygments library. The
style argument exposes access to any style by name that can be found by pygments, and there are sev-
eral already installed. The colors argument, if unspecified, will be guessed based on the chosen style.
Similarly, there are default styles associated with each colors option.
Screenshot of ipython qtconsole --colors=linux, which uses the ‘monokai’ theme by default:
Note: Calling ipython qtconsole -h will show all the style names that pygments can find on your
system.
You can also pass the filename of a custom CSS stylesheet, if you want to do your own coloring, via the
stylesheet argument. The default LightBG stylesheet:
Fonts
The QtConsole has configurable via the ConsoleWidget. To change these, set the font_family or
font_size traits of the ConsoleWidget. For instance, to use 9pt Anonymous Pro:
$> ipython qtconsole --ConsoleWidget.font_family="Anonymous Pro" --
˓→ConsoleWidget.font_size=9
Process Management
With the two-process ZMQ model, the frontend does not block input during execution. This means that
actions can be taken by the frontend while the Kernel is executing, or even after it crashes. The most
basic such command is via ‘Ctrl-.’, which restarts the kernel. This can be done in the middle of a blocking
execution. The frontend can also know, via a heartbeat mechanism, that the kernel has died. This means that
the frontend can safely restart the kernel.
Multiple Consoles
Since the Kernel listens on the network, multiple frontends can connect to it. These do not have to all be qt
frontends - any IPython frontend can connect and run code. When you start ipython qtconsole, there will be
an output line, like:
[IPKernelApp] To connect another client to this kernel, use:
[IPKernelApp] --existing kernel-12345.json
Other frontends can connect to your kernel, and share in the execution. This is great for collaboration. The
--existing flag means connect to a kernel that already exists. Starting other consoles with that flag will
not try to start their own kernel, but rather connect to yours. kernel-12345.json is a small JSON file
with the ip, port, and authentication information necessary to connect to your kernel. By default, this file
will be in your default profile’s security directory. If it is somewhere else, the output line will print the full
path of the connection file, rather than just its filename.
If you need to find the connection info to send, and don’t know where your connection file lives, there are
a couple of ways to get it. If you are already running an IPython console connected to the kernel, you can
use the %connect_info magic to display the information necessary to connect another frontend to the
kernel.
In [2]: %connect_info
{
"stdin_port":50255,
"ip":"127.0.0.1",
"hb_port":50256,
"key":"70be6f0f-1564-4218-8cda-31be40a4d6aa",
"shell_port":50253,
"iopub_port":50254
}
Otherwise, you can find a connection file by name (and optionally profile) with IPython.lib.kernel.
find_connection_file():
You can even launch a standalone kernel, and connect and disconnect Qt Consoles from various machines.
This lets you keep the same running IPython session on your work machine (with matplotlib plots and
everything), logging in from home, cafés, etc.:
This is actually exactly the same as the subprocess launched by the qtconsole, so all the information about
connecting to a standalone kernel is identical to that of connecting to the kernel attached to a running console.
Security
Warning: Since the ZMQ code currently has no encryption, listening on an external-facing IP is
dangerous. You are giving any computer that can see you on the network the ability to connect to your
kernel, and view your traffic. Read the rest of this section before listening on external ports or running
an IPython kernel on a shared machine.
By default (for security reasons), the kernel only listens on localhost, so you can only connect multiple
frontends to the kernel from your local machine. You can specify to listen on an external interface by
specifying the ip argument:
If you specify the ip as 0.0.0.0 or ‘*’, that means all interfaces, so any computer that can see yours on the
network can connect to the kernel.
Messages are not encrypted, so users with access to the ports your kernel is using will be able to see any
output of the kernel. They will NOT be able to issue shell commands as you due to message signatures,
which are enabled by default as of IPython 0.12.
Warning: If you disable message signatures, then any user with access to the ports your kernel is
listening on can issue arbitrary code as you. DO NOT disable message signatures unless you have a lot
of trust in your environment.
The one security feature IPython does provide is protection from unauthorized execution. IPython’s mes-
saging system will sign messages with HMAC digests using a shared-key. The key is never sent over the
network, it is only used to generate a unique hash for each message, based on its content. When IPython
receives a message, it will check that the digest matches, and discard the message. You can use any file
that only you have access to to generate this key, but the default is just to generate a new UUID. You can
generate a random private key with:
# generate 1024b of random data, and store in a file only you can read:
# (assumes IPYTHONDIR is defined, otherwise use your IPython directory)
$> python -c "import os; print os.urandom(128).encode('base64')" >
˓→$IPYTHONDIR/sessionkey
$> chmod 600 $IPYTHONDIR/sessionkey
The contents of this file will be stored in the JSON connection file, so that file contains everything you need
to connect to and use a kernel.
To use this generated key, simply specify the Session.keyfile configurable in ipython_config.
py or at the command-line, as in:
# instruct IPython to sign messages with that key, instead of a new UUID
$> ipython qtconsole --Session.keyfile=$IPYTHONDIR/sessionkey
SSH Tunnels
Sometimes you want to connect to machines across the internet, or just across a LAN that either doesn’t
permit open ports or you don’t trust the other machines on the network. To do this, you can use SSH tunnels.
SSH tunnels are a way to securely forward ports on your local machine to ports on another machine, to which
you have SSH access.
In simple cases, IPython’s tools can forward ports over ssh by simply adding the --ssh=remote argument
to the usual --existing... set of flags for connecting to a running kernel, after copying the JSON
connection file (or its contents) to the second computer.
Warning: Using SSH tunnels does not increase localhost security. In fact, when tunneling from one
machine to another both machines have open ports on localhost available for connections to the kernel.
There are two primary models for using SSH tunnels with IPython. The first is to have the Kernel listen only
on localhost, and connect to it from another machine on the same LAN.
First, let’s start a kernel on machine worker, listening only on loopback:
In this case, the IP that you would connect to would still be 127.0.0.1, but you want to specify the additional
--ssh argument with the hostname of the kernel (in this example, it’s ‘worker’):
Which will write a new connection file with the forwarded ports, so you can reuse them:
Note again that this opens ports on the client machine that point to your kernel.
Note: the ssh argument is simply passed to openssh, so it can be fully specified user@host:port but it
will also respect your aliases, etc. in .ssh/config if you have any.
The second pattern is for connecting to a machine behind a firewall across the internet (or otherwise wide
network). This time, we have a machine login that you have ssh access to, which can see kernel, but client
is on another network. The important difference now is that client can see login, but not worker. So we
need to forward ports from client to worker via login. This means that the kernel must be started listening
on external interfaces, so that its ports are visible to login:
Note: The IP here is the address of worker as seen from login, and need only be specified if the kernel used
the ambiguous 0.0.0.0 (all interfaces) address. If it had used 192.168.1.123 to start with, it would not be
needed.
It’s possible that IPython’s ssh helper functions won’t work for you, for various reasons. You can still
connect to remote machines, as long as you set up the tunnels yourself. The basic format of forwarding a
local port to a remote one is:
This will forward local connections to localport on client to remoteip:remoteport via server. Note that
remoteip is interpreted relative to server, not the client. So if you have direct ssh access to the machine
to which you want to forward connections, then the server is the remote machine, and remoteip should be
server’s IP as seen from the server itself, i.e. 127.0.0.1. Thus, to forward local port 12345 to remote port
54321 on a machine you can see, do:
But if your target is actually on a LAN at 192.168.1.123, behind another machine called login, then you
would do:
The -f -N on the end are flags that tell ssh to run in the background, and don’t actually run any commands
beyond creating the tunnel.
See also:
A short discussion of ssh tunnels: http://www.revsys.com/writings/quicktips/ssh-tunnel.html
Since there can be many consoles per kernel, the shutdown mechanism and dialog are probably more com-
plicated than you are used to. Since you don’t always want to shutdown a kernel when you close a window,
you are given the option to just close the console window or also close the Kernel and all other windows.
Note that this only refers to all other local windows, as remote Consoles are not allowed to shutdown the
kernel, and shutdowns do not close Remote consoles (to allow for saving, etc.).
Rules:
• Restarting the kernel automatically clears all local Consoles, and prompts remote Consoles about the
reset.
• Shutdown closes all local Consoles, and notifies remotes that the Kernel has been shutdown.
• Remote Consoles may not restart or shutdown the kernel.
An important part of working with the QtConsole when you are writing your own Qt code is to remember
that user code (in the kernel) is not in the same process as the frontend. This means that there is not neces-
sarily any Qt code running in the kernel, and under most normal circumstances there isn’t. If, however, you
A common problem listed in the PyQt4 Gotchas is the fact that Python’s garbage collection will destroy Qt
objects (Windows, etc.) once there is no longer a Python reference to them, so you have to hold on to them.
For instance, in:
def make_window():
win = QtGui.QMainWindow()
def make_and_return_window():
win = QtGui.QMainWindow()
return win
make_window() will never draw a window, because garbage collection will destroy it before it is drawn,
whereas make_and_return_window() lets the caller decide when the window object should be de-
stroyed. If, as a developer, you know that you always want your objects to last as long as the process, you
can attach them to the QApplication instance itself:
Now the QApplication itself holds a reference to win, so it will never be garbage collected until the appli-
cation itself is destroyed.
In order to make the QtConsole available to an external Qt GUI application (just as IPython.embed()
enables one to embed a terminal session of IPython in a command-line application), there are a few options:
• First start IPython, and then start the external Qt application from IPython, as described above. Effec-
tively, this embeds your application in IPython rather than the other way round.
• Use IPython.qt.console.rich_ipython_widget.RichIPythonWidget in your Qt
application. This will embed the console widget in your GUI and start the kernel in a separate process,
so code typed into the console cannot access objects in your application.
• Start a standard IPython kernel in the process of the external Qt application. See examples/lib/
ipkernel_qtapp.py for an example. Due to IPython’s two-process model, the QtConsole itself
will live in another process with its own QApplication, and thus cannot be embedded in the main GUI.
• Start a special IPython kernel, the IPython.kernel.inprocess.ipkernel.
InProcessKernel, that allows a QtConsole in the same process. See examples/inprocess/
embedded_qtconsole.py for an example. While the QtConsole can now be embedded in the
main GUI, one cannot connect to the kernel from other consoles as there are no real ZMQ sockets
anymore.
Regressions
There are some features, where the qt console lags behind the Terminal frontend:
• !cmd input: Due to our use of pexpect, we cannot pass input to subprocesses launched using the
‘!’ escape, so you should never call a command that requires interactive input. For such cases, use
the terminal IPython. This will not be fixed, as abandoning pexpect would significantly degrade the
console experience.
See also:
The IPython notebook
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Introduction
The notebook extends the console-based approach to interactive computing in a qualitatively new direction,
providing a web-based application suitable for capturing the whole computation process: developing, doc-
umenting, and executing code, as well as communicating the results. The IPython notebook combines two
components:
A web application: a browser-based tool for interactive authoring of documents which combine explanatory
text, mathematics, computations and their rich media output.
Notebook documents: a representation of all content visible in the web application, including inputs and
outputs of the computations, explanatory text, mathematics, images, and rich media representations of ob-
jects.
See also:
See the installation documentation for directions on how to install the notebook and its dependencies.
299
IPython Documentation, Release 3.0.0-dev
• In-browser editing for code, with automatic syntax highlighting, indentation, and tab comple-
tion/introspection.
• The ability to execute code from the browser, with the results of computations attached to the code
which generated them.
• Displaying the result of computation using rich media representations, such as HTML, LaTeX, PNG,
SVG, etc. For example, publication-quality figures rendered by the matplotlib library, can be included
inline.
• In-browser editing for rich text using the Markdown markup language, which can provide commentary
for the code, is not limited to plain text.
• The ability to easily include mathematical notation within markdown cells using LaTeX, and rendered
natively by MathJax.
Notebook documents
Notebook documents contains the inputs and outputs of a interactive session as well as additional text that
accompanies the code but is not meant for execution. In this way, notebook files can serve as a complete
computational record of a session, interleaving executable code with explanatory text, mathematics, and
rich representations of resulting objects. These documents are internally JSON files and are saved with
the .ipynb extension. Since JSON is a plain text format, they can be version-controlled and shared with
colleagues.
Notebooks may be exported to a range of static formats, including HTML (for example, for blog posts),
reStructuredText, LaTeX, PDF, and slide shows, via the new nbconvert command.
Furthermore, any .ipynb notebook document available from a public URL can be shared via the IPython
Notebook Viewer (nbviewer). This service loads the notebook document from the URL and renders it as a
static web page. The results may thus be shared with a colleague, or as a public blog post, without other
users needing to install IPython themselves. In effect, nbviewer is simply nbconvert as a web service, so
you can do your own static conversions with nbconvert, without relying on nbviewer.
See also:
Details on the notebook JSON file format
You can start running a notebook server from the command line using the following command:
ipython notebook
This will print some information about the notebook server in your console, and open a web browser to the
URL of the web application (by default, http://127.0.0.1:8888).
The landing page of the IPython notebook web application, the dashboard, shows the notebooks currently
available in the notebook directory (by default, the directory from which the notebook server was started).
You can create new notebooks from the dashboard with the New Notebook button, or open existing ones
by clicking on their name. You can also drag and drop .ipynb notebooks and standard .py Python source
code files into the notebook list area.
When starting a notebook server from the command line, you can also open a particular notebook directly,
bypassing the dashboard, with ipython notebook my_notebook.ipynb. The .ipynb extension
is assumed if no extension is given.
When you are inside an open notebook, the File | Open... menu option will open the dashboard in
a new browser tab, to allow you to open another notebook from the notebook directory or to create a new
notebook.
Note: You can start more than one notebook server at the same time, if you want to work on notebooks
in different directories. By default the first notebook server starts on port 8888, and later notebook servers
search for ports near that one. You can also manually specify the port with the --port option.
A new notebook may be created at any time, either from the dashboard, or using the File | New menu
option from within an active notebook. The new notebook is created within the same directory and will
open in a new browser tab. It will also be reflected as a new entry in the notebook list on the dashboard.
Opening notebooks
An open notebook has exactly one interactive session connected to an IPython kernel, which will execute
code sent by the user and communicate back results. This kernel remains active if the web browser window
is closed, and reopening the same notebook from the dashboard will reconnect the web application to the
same kernel. In the dashboard, notebooks with an active kernel have a Shutdown button next to them,
whereas notebooks without an active kernel have a Delete button in its place.
Other clients may connect to the same underlying IPython kernel. The notebook server always prints to the
terminal the full details of how to connect to each kernel, with messages such as the following:
This long string is the kernel’s ID which is sufficient for getting the information necessary to connect to the
kernel. You can also request this connection data by running the %connect_info magic. This will print
the same ID information as well as the content of the JSON data structure it contains.
You can then, for example, manually start a Qt console connected to the same kernel from the command
line, by passing a portion of the ID:
Without an ID, --existing will connect to the most recently started kernel. This can also be done by
running the %qtconsole magic in the notebook.
See also:
When you create a new notebook document, you will be presented with the notebook name, a menu bar,
a toolbar and an empty code cell.
notebook name: The name of the notebook document is displayed at the top of the page, next to the
IP[y]: Notebook logo. This name reflects the name of the .ipynb notebook document file. Clicking
on the notebook name brings up a dialog which allows you to rename it. Thus, renaming a notebook from
“Untitled0” to “My first notebook” in the browser, renames the Untitled0.ipynb file to My first
notebook.ipynb.
menu bar: The menu bar presents different options that may be used to manipulate the way the notebook
functions.
toolbar: The tool bar gives a quick way of performing the most-used operations within the notebook, by
clicking on an icon.
code cell: the default type of cell, read on for an explanation of cells
The notebook consists of a sequence of cells. A cell is a multi-line text input field, and its contents can be
executed by using Shift-Enter, or by clicking either the “Play” button the toolbar, or Cell | Run in
the menu bar. The execution behavior of a cell is determined the cell’s type. There are four types of cells:
code cells, markdown cells, raw cells and heading cells. Every cell starts off being a code cell, but its
type can be changed by using a dropdown on the toolbar (which will be “Code”, initially), or via keyboard
shortcuts.
For more information on the different things you can do in a notebook, see the collection of examples.
Code cells
A code cell allows you to edit and write new code, with full syntax highlighting and tab completion. By
default, the language associated to a code cell is Python, but other languages, such as Julia and R, can be
handled using cell magic commands.
When a code cell is executed, code that it contains is sent to the kernel associated with the notebook.
The results that are returned from this computation are then displayed in the notebook as the cell’s output.
The output is not limited to text, with many other possible forms of output are also possible, including
matplotlib figures and HTML tables (as used, for example, in the pandas data analysis package). This
is known as IPython’s rich display capability.
See also:
Basic Output example notebook
Rich Display System example notebook
Markdown cells
You can document the computational process in a literate way, alternating descriptive text with code, using
rich text. In IPython this is accomplished by marking up text with the Markdown language. The correspond-
ing cells are called Markdown cells. The Markdown language provides a simple way to perform this text
markup, that is, to specify which parts of the text should be emphasized (italics), bold, form lists, etc.
When a Markdown cell is executed, the Markdown code is converted into the corresponding formatted rich
text. Markdown allows arbitrary HTML code for formatting.
Within Markdown cells, you can also include mathematics in a straightforward way, using standard LaTeX
notation: $...$ for inline mathematics and $$...$$ for displayed mathematics. When the Markdown
cell is executed, the LaTeX portions are automatically rendered in the HTML output as equations with high
quality typography. This is made possible by MathJax, which supports a large subset of LaTeX functionality
Standard mathematics environments defined by LaTeX and AMS-LaTeX (the amsmath pack-
age) also work, such as \begin{equation}...\end{equation}, and \begin{align}...
\end{align}. New LaTeX macros may be defined using standard methods, such as \newcommand,
by placing them anywhere between math delimiters in a Markdown cell. These definitions are then available
throughout the rest of the IPython session.
See also:
Markdown Cells example notebook
Raw cells
Raw cells provide a place in which you can write output directly. Raw cells are not evaluated by the
notebook. When passed through nbconvert, raw cells arrive in the destination format unmodified. For
example, this allows you to type full LaTeX into a raw cell, which will only be rendered by LaTeX after
conversion by nbconvert.
Heading cells
You can provide a conceptual structure for your computational document as a whole using different levels
of headings; there are 6 levels available, from level 1 (top level) down to level 6 (paragraph). These can be
used later for constructing tables of contents, etc. As with Markdown cells, a heading cell is replaced by a
rich text rendering of the heading when the cell is executed.
Basic workflow
The normal workflow in a notebook is, then, quite similar to a standard IPython session, with the difference
that you can edit cells in-place multiple times until you obtain the desired results, rather than having to rerun
separate scripts with the %run magic command.
Typically, you will work on a computational problem in pieces, organizing related ideas into cells and mov-
ing forward once previous parts work correctly. This is much more convenient for interactive exploration
than breaking up a computation into scripts that must be executed together, as was previously necessary,
especially if parts of them take a long time to run.
At certain moments, it may be necessary to interrupt a calculation which is taking too long to complete.
This may be done with the Kernel | Interrupt menu option, or the Ctrl-m i keyboard shortcut.
Similarly, it may be necessary or desirable to restart the whole computational process, with the Kernel |
Restart menu option or Ctrl-m . shortcut.
A notebook may be downloaded in either a .ipynb or .py file from the menu option File |
Download as. Choosing the .py option downloads a Python .py script, in which all rich output has
been removed and the content of markdown cells have been inserted as comments.
See also:
Running Code in the IPython Notebook example notebook
Basic Output example notebook
a warning about doing “roundtrip” conversions.
Keyboard shortcuts
All actions in the notebook can be performed with the mouse, but keyboard shortcuts are also available for
the most common ones. The essential shortcuts to remember are the following:
• Shift-Enter: run cell Execute the current cell, show output (if any), and jump to the next cell
below. If Shift-Enter is invoked on the last cell, a new code cell will also be created. Note
that in the notebook, typing Enter on its own never forces execution, but rather just inserts a
new line in the current cell. Shift-Enter is equivalent to clicking the Cell | Run menu
item.
• Ctrl-Enter: run cell in-place Execute the current cell as if it were in “terminal mode”, where any
output is shown, but the cursor remains in the current cell. The cell’s entire contents are selected
after execution, so you can just start typing and only the new input will be in the cell. This is
convenient for doing quick experiments in place, or for querying things like filesystem content,
without needing to create additional cells that you may not want to be saved in the notebook.
• Alt-Enter: run cell, insert below Executes the current cell, shows the output, and inserts a new
cell between the current cell and the cell below (if one exists). This is thus a shortcut for the
sequence Shift-Enter, Ctrl-m a. (Ctrl-m a adds a new cell above the current one.)
• Esc and Enter: Command mode and edit mode In command mode, you can easily navigate
around the notebook using keyboard shortcuts. In edit mode, you can edit text in cells.
For the full list of available shortcuts, click Help, Keyboard Shortcuts in the notebook menus.
Plotting
One major feature of the notebook is the ability to display plots that are the output of running code cells.
IPython is designed to work seamlessly with the matplotlib plotting library to provide this functionality.
To set this up, before any plotting is performed you must execute the %matplotlib magic command.
This performs the necessary behind-the-scenes setup for IPython to work correctly hand in hand with
matplotlib; it does not, however, actually execute any Python import commands, that is, no names
are added to the namespace.
If the %matplotlib magic is called without an argument, the output of a plotting command is displayed
using the default matplotlib backend in a separate window. Alternatively, the backend can be explicitly
requested using, for example:
%matplotlib gtk
A particularly interesting backend, provided by IPython, is the inline backend. This is available only for
the IPython Notebook and the IPython QtConsole. It can be invoked as follows:
%matplotlib inline
With this backend, the output of plotting commands is displayed inline within the notebook, directly below
the code cell that produced it. The resulting plots will then also be stored in the notebook document.
See also:
Plotting with Matplotlib example notebook
The notebook server can be run with a variety of command line arguments. To see a list of available options
enter:
Defaults for these options can also be set by creating a file named ipython_notebook_config.py in
your IPython profile folder. The profile folder is a subfolder of your IPython directory; to find out where it
is located, run:
$ ipython locate
To create a new set of default configuration files, with lots of information on available options, use:
See also:
Overview of the IPython configuration system, in particular Profiles.
Securing a notebook server
Running a public notebook server
Signing Notebooks
To prevent untrusted code from executing on users’ behalf when notebooks open, we have added a signature
to the notebook, stored in metadata. The notebook server verifies this signature when a notebook is opened.
If the signature stored in the notebook metadata does not match, javascript and HTML output will not be
displayed on load, and must be regenerated by re-executing the cells.
Any notebook that you have executed yourself in its entirety will be considered trusted, and its HTML and
javascript output will be displayed on load.
If you need to see HTML or Javascript output without re-executing, you can explicitly trust notebooks, such
as those shared with you, or those that you have written yourself prior to IPython 2.0, at the command-line
with:
.py files will be imported as a notebook with the same basename, but an .ipynb extension, located in the
notebook directory. The notebook created will have just one cell, which will contain all the code in the .py
file. You can later manually partition this into individual cells using the Edit | Split Cell menu
option, or the Ctrl-m - keyboard shortcut.
Note that .py scripts obtained from a notebook document using nbconvert maintain the structure of the
notebook in comments. Reimporting such a script back into a notebook will preserve this structure.
Warning: While in simple cases you can “roundtrip” a notebook to Python, edit the Python file, and
then import it back without loss of main content, this is in general not guaranteed to work. First, there
is extra metadata saved in the notebook that may not be saved to the .py format. And as the notebook
format evolves in complexity, there will be attributes of the notebook that will not survive a roundtrip
through the Python form. You should think of the Python format as a way to output a script version of
a notebook and the import capabilities as a way to load existing code to get a notebook started. But the
Python version is not an alternate notebook format.
See also:
LaTeX citations
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Introduction
Jupyter (né IPython) notebook files are simple JSON documents, containing text, source code, rich media
output, and metadata. each segment of the document is stored in a cell.
Some general points about the notebook format:
Note: All metadata fields are optional. While the type and values of some metadata are defined, no metadata
values are required to be defined.
Top-level structure
{
"metadata" : {
"signature": "hex-digest", # used for authenticating unsafe outputs on
˓→load
"kernel_info": {
# if kernel_info is defined, its name field is required.
"name" : "the name of the kernel"
},
"language_info": {
# if language_info is defined, its name field is required.
"name" : "the programming language of the kernel",
"version": "the version of the language",
"codemirror_mode": "The name of the codemirror mode to use [optional]"
}
},
"nbformat": 4,
"nbformat_minor": 0,
"cells" : [
# list of cell dictionaries, see below
],
}
Some fields, such as code input and text output, are characteristically multi-line strings. When these fields
are written to disk, they may be written as a list of strings, which should be joined with '' when reading
back into memory. In programmatic APIs for working with notebooks (Python, Javascript), these are always
re-joined into the original multi-line string. If you intend to work with notebook files directly, you must allow
multi-line string fields to be either a string or list of strings.
Cell Types
There are a few basic cell types for encapsulating code and text. All cells have the following basic structure:
{
"cell_type" : "name",
"metadata" : {},
"source" : "single string or [list, of, strings]",
}
Markdown cells
Markdown cells are used for body-text, and contain markdown, as defined in GitHub-flavored markdown,
and implemented in marked.
{
"cell_type" : "markdown",
"metadata" : {},
"source" : ["some *markdown*"],
}
Code cells
Code cells are the primary content of Jupyter notebooks. They contain source code in the language of the
document’s associated kernel, and a list of outputs associated with executing that code. They also have an
execution_count, which must be an integer or null.
{
"cell_type" : "code",
"execution_count": 1, # integer or null
"metadata" : {
"collapsed" : True, # whether the output of the cell is collapsed
"autoscroll": False, # any of true, false or "auto"
},
"source" : ["some code"],
"outputs": [{
# list of output dicts (described below)
"output_type": "stream",
...
}],
}
A code cell can have a variety of outputs (stream data or rich mime-type output). These correspond to
messages produced as a result of executing the cell.
All outputs have an output_type field, which is a string defining what type of output it is.
stream output
{
"output_type" : "stream",
"name" : "stdout", # or stderr
"data" : ["multiline stream text"],
}
display_data
Rich display outputs, as created by display_data messages, contain data keyed by mime-type. This is
often called a mime-bundle, and shows up in various locations in the notebook format and message spec.
The metadata of these messages may be keyed by mime-type as well.
{
"output_type" : "display_data",
"data" : {
"text/plain" : ["multiline text data"],
"image/png": ["base64-encoded-png-data"],
"application/json": {
# JSON data is included as-is
"json": "data",
},
},
"metadata" : {
"image/png": {
"width": 640,
"height": 480,
},
},
}
execute_result
Results of executing a cell (as created by displayhook in Python) are stored in execute_result out-
puts. execute_result outputs are identical to display_data, adding only a execution_count
field, which must be an integer.
{
"output_type" : "execute_result",
"execution_count": 42,
"data" : {
"text/plain" : ["multiline text data"],
"image/png": ["base64-encoded-png-data"],
"application/json": {
# JSON data is included as-is
"json": "data",
},
},
"metadata" : {
"image/png": {
"width": 640,
"height": 480,
},
},
}
error
A raw cell is defined as content that should be included unmodified in nbconvert output. For example,
this cell could include raw LaTeX for nbconvert to pdf via latex, or restructured text for use in Sphinx
documentation.
The notebook authoring environment does not render raw cells.
The only logic in a raw cell is the format metadata field. If defined, it specifies which nbconvert output
format is the intended target for the raw cell. When outputting to any other format, the raw cell’s contents
will be excluded. In the default case when this value is undefined, a raw cell’s contents will be included in
any nbconvert output, regardless of format.
{
"cell_type" : "raw",
"metadata" : {
# the mime-type of the target nbconvert format.
# nbconvert to formats other than this will exclude this cell.
"format" : "mime/type"
},
"source" : ["some nbformat mime-type data"]
}
Metadata
Metadata is a place that you can put arbitrary JSONable information about your notebook, cell, or output.
Because it is a shared namespace, any custom metadata should use a sufficiently unique namespace, such as
metadata.kaylees_md.foo = "bar".
Metadata fields officially defined for Jupyter notebooks are listed here:
Notebook metadata
Cell metadata
Output metadata
The following metadata keys are defined for code cell outputs:
Key Value Interpretation
isolated bool Whether the output should be isolated into an IFrame
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Newly added in the 1.0 release of IPython is the nbconvert tool, which allows you to convert an .ipynb
notebook document file into various static formats.
Currently, nbconvert is provided as a command line tool, run as a script using IPython. A direct export
capability from within the IPython Notebook web app is planned.
The command-line syntax to run the nbconvert script is:
This will convert the IPython document file notebook.ipynb into the output format given by the
FORMAT string.
The default output format is html, for which the --to argument may be omitted:
IPython provides a few templates for some output formats, and these can be specified via an additional
--template argument.
The currently supported export formats are:
• --to html
Note: nbconvert uses pandoc to convert between various markup languages, so pandoc is a dependency of
most nbconvert transforms, excluding Markdown and Python.
The output file created by nbconvert will have the same base name as the notebook and will be placed
in the current working directory. Any supporting files (graphics, etc) will be placed in a new directory with
the same base name as the notebook, suffixed with _files:
For simple single-file output, such as html, markdown, etc., the output may be sent to standard output with:
c = get_config()
c.NbConvertApp.notebooks = ["notebook1.ipynb", "notebook2.ipynb"]
LaTeX citations
nbconvert now has support for LaTeX citations. With this capability you can:
• Manage citations using BibTeX.
• Cite those citations in Markdown cells using HTML data attributes.
• Have nbconvert generate proper LaTeX citations and run BibTeX.
For an example of how this works, please see the citations example in the nbconvert-examples repository.
Notebook documents are JSON files with an .ipynb extension, formatted as legibly as possible with
minimal extra indentation and cell content broken across lines to make them reasonably friendly to use
in version-control workflows. You should be very careful if you ever manually edit this JSON data, as it
is extremely easy to corrupt its internal structure and make the file impossible to load. In general, you
should consider the notebook as a file meant only to be edited by the IPython Notebook app itself, not for
hand-editing.
Note: Binary data such as figures are also saved directly in the JSON file. This provides convenient single-
file portability, but means that the files can be large; a diff of binary data is also not very meaningful.
Since the binary blobs are encoded in a single line, they affect only one line of the diff output, but they
are typically very long lines. You can use the Cell | All Output | Clear menu option to remove
all output from a notebook prior to committing it to version control, if this is a concern.
The notebook server can also generate a pure Python version of your notebook, using the File |
Download as menu option. The resulting .py file will contain all the code cells from your notebook
verbatim, and all Markdown cells prepended with a comment marker. The separation between code and
Markdown cells is indicated with special comments and there is a header indicating the format version. All
output is removed when exporting to Python.
As an example, consider a simple notebook called simple.ipynb which contains one Markdown cell,
with the content The simplest notebook., one code input cell with the content print "Hello,
IPython!", and the corresponding output.
The contents of the notebook document simple.ipynb is the following JSON container:
{
"metadata": {
"name": "simple"
},
"nbformat": 3,
"nbformat_minor": 0,
"worksheets": [
{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": "The simplest notebook."
},
{
"cell_type": "code",
"collapsed": false,
"input": "print \"Hello, IPython\"",
"language": "python",
"metadata": {},
"outputs": [
{
"output_type": "stream",
"stream": "stdout",
"text": "Hello, IPython\n"
}
],
"prompt_number": 1
}
],
"metadata": {}
}
]
}
# <markdowncell>
# <codecell>
Note that indeed the output of the code cell, which is present in the JSON container, has been removed in
the .py script.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
The IPython notebook web-application is based on a server-client structure. This server uses a two-process
kernel architecture based on ZeroMQ, as well as Tornado for serving HTTP requests. By default, a notebook
server runs on http://127.0.0.1:8888/ and is accessible only from localhost. This document describes
how you can secure a notebook server and how to run it on a public interface.
You can protect your notebook server with a simple single password by setting the NotebookApp.
password configurable. You can prepare a hashed password using the function IPython.lib.
security.passwd():
Note: passwd() can also take the password as a string argument. Do not pass it as an argument inside
an IPython session, as it will be saved in your input history.
When using a password, it is a good idea to also use SSL, so that your password is not sent unencrypted by
your browser. You can start the notebook to communicate via a secure protocol mode using a self-signed
Note: A self-signed certificate can be generated with openssl. For example, the following command
will create a certificate valid for 365 days with both the key and certificate data written to the same file:
$ openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out
˓→mycert.pem
Your browser will warn you of a dangerous certificate because it is self-signed. If you want to have a
fully compliant certificate that will not raise warnings, it is possible (but rather involved) to obtain one, as
explained in detail in this tutorial.
Keep in mind that when you enable SSL support, you will need to access the notebook server over https:/
/, not over plain http://. The startup message from the server prints this, but it is easy to overlook and
think the server is for some reason non-responsive.
If you want to access your notebook server remotely via a web browser, you can do the following.
Start by creating a certificate file and a hashed password, as explained above. Then create a custom profile
for the notebook, with the following command line, type:
In the profile directory just created, edit the file ipython_notebook_config.py. By default, the file
has all fields commented; the minimum set you need to uncomment and edit is the following:
c = get_config()
# Notebook config
c.NotebookApp.certfile = u'/absolute/path/to/your/certificate/mycert.pem'
c.NotebookApp.ip = '*'
c.NotebookApp.open_browser = False
c.NotebookApp.password = u'sha1:bcd259ccf...[your hashed password here]'
# It is a good idea to put it on a known, fixed port
c.NotebookApp.port = 9999
You can then start the notebook and access it later by pointing your browser to https://your.host.
com:9999 with ipython notebook --profile=nbserver.
Firewall Setup
To function correctly, the firewall on the computer running the ipython server must be configured to allow
connections from client machines on the c.NotebookApp.port port to allow connections to the web
interface. The firewall must also allow connections from 127.0.0.1 (localhost) on ports from 49152 to 65535.
These ports are used by the server to communicate with the notebook kernels. The kernel communication
ports are chosen randomly by ZeroMQ, and may require multiple connections per kernel, so a large range
of ports must be accessible.
The notebook dashboard (the landing page with an overview of the notebooks in your working direc-
tory) typically lives at the URL http://localhost:8888/. If you prefer that it lives, together
with the rest of the notebook, under a sub-directory, e.g. http://localhost:8888/ipython/,
you can do so with configuration options like the following (see above for instructions about modifying
ipython_notebook_config.py):
c.NotebookApp.base_url = '/ipython/'
c.NotebookApp.webapp_settings = {'static_url_prefix':'/ipython/static/'}
By default, the notebook server stores the notebook documents that it saves as files in the working di-
rectory of the notebook server, also known as the notebook_dir. This logic is implemented in the
FileNotebookManager class. However, the server can be configured to use a different notebook man-
ager class, which can store the notebooks in a different format.
The bookstore package currently allows users to store notebooks on Rackspace CloudFiles or OpenStack
Swift based object stores.
Writing a notebook manager is as simple as extending the base class NotebookManager. The sim-
ple_notebook_manager provides a great example of an in memory notebook manager, created solely for the
purpose of illustrating the notebook manager API.
Known issues
When behind a proxy, especially if your system or browser is set to autodetect the proxy, the notebook web
application might fail to connect to the server’s websockets, and present you with a warning at startup. In
this case, you need to configure your system not to use the proxy for the server’s address.
For example, in Firefox, go to the Preferences panel, Advanced section, Network tab, click ‘Settings...’, and
add the address of the notebook server to the ‘No proxy for’ field.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
As IPython notebooks become more popular for sharing and collaboration, the potential for malicious people
to attempt to exploit the notebook for their nefarious purposes increases. IPython 2.0 introduces a security
model to prevent execution of untrusted code without explicit user input.
The problem
The whole point of IPython is arbitrary code execution. We have no desire to limit what can be done with a
notebook, which would negatively impact its utility.
Unlike other programs, an IPython notebook document includes output. Unlike other documents, that output
exists in a context that can execute code (via Javascript).
The security problem we need to solve is that no code should execute just because a user has opened
a notebook that they did not write. Like any other program, once a user decides to execute code in a
notebook, it is considered trusted, and should be allowed to do anything.
IPython notebooks store a signature in metadata, which is used to answer the question “Did the current user
do this?”
This signature is a digest of the notebooks contents plus a secret key, known only to the user. The secret key
is a user-only readable file in the IPython profile’s security directory. By default, this is:
~/.ipython/profile_default/security/notebook_secret
Note: The notebook secret being stored in the profile means that loading a notebook in another profile
results in it being untrusted, unless you copy or symlink the notebook secret to share it across profiles.
When a notebook is opened by a user, the server computes a signature with the user’s key, and compares it
with the signature stored in the notebook’s metadata. If the signature matches, HTML and Javascript output
in the notebook will be trusted at load, otherwise it will be untrusted.
Updating trust
A notebook’s trust is updated when the notebook is saved. If there are any untrusted outputs still in the
notebook, the notebook will not be trusted, and no signature will be stored. If all untrusted outputs have
been removed (either via Clear Output or re-execution), then the notebook will become trusted.
While trust is updated per output, this is only for the duration of a single session. A notebook file on disk is
either trusted or not in its entirety.
Explicit trust
Sometimes re-executing a notebook to generate trusted output is not an option, either because dependencies
are unavailable, or it would take a long time. Users can explicitly trust a notebook in two ways:
• At the command-line, with:
If you find a security vulnerability in IPython, either a failure of the code to properly implement the model
described here, or a failure of the model itself, please report it to [email protected].
If you prefer to encrypt your security reports, you can use this PGP public key.
Some use cases that work in IPython 1.0 will become less convenient in 2.0 as a result of the security
changes. We do our best to minimize these annoyance, but security is always at odds with convenience.
While never officially supported, it had become common practice to put hidden Javascript or CSS styling in
Markdown cells, so that they would not be visible on the page. Since Markdown cells are now sanitized (by
Google Caja), all Javascript (including click event handlers, etc.) and CSS will be stripped.
We plan to provide a mechanism for notebook themes, but in the meantime styling the notebook can only
be done via either custom.css or CSS in HTML output. The latter only have an effect if the notebook is
trusted, because otherwise the output will be sanitized just like Markdown.
Collaboration
When collaborating on a notebook, people probably want to see the outputs produced by their colleagues’
most recent executions. Since each collaborator’s key will differ, this will result in each share starting in an
untrusted state. There are three basic approaches to this:
• re-run notebooks when you get them (not always viable)
• explicitly trust notebooks via ipython trust or the notebook menu (annoying, but easy)
• share a notebook secret, and use an IPython profile dedicated to the collaboration while working on
the project.
Since the notebook secret is stored in a profile directory by default, opening a notebook with a different
profile or on a different machine will result in a different key, and thus be untrusted. The only current way
to address this is by sharing the notebook secret. This can be facilitated by setting the configurable:
c.NotebookApp.secret_file = "/path/to/notebook_secret"
in each profile, and only sharing the secret once per machine.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Examples
We have various example scripts and notebooks for using IPython.parallel in our examples/
Parallel%20Computing directory, or they can be viewed using nbviewer. Some of these are covered
in more detail in the examples section.
Introduction
This section gives an overview of IPython’s sophisticated and powerful architecture for parallel and dis-
tributed computing. This architecture abstracts out parallelism in a very general way, which enables IPython
to support many different styles of parallelism including:
• Single program, multiple data (SPMD) parallelism.
• Multiple program, multiple data (MPMD) parallelism.
• Message passing using MPI.
• Task farming.
• Data parallel.
323
IPython Documentation, Release 3.0.0-dev
Tip: At the SciPy 2011 conference in Austin, Min Ragan-Kelley presented a complete 4-hour tutorial on
the use of these features, and all the materials for the tutorial are now available online. That tutorial provides
an excellent, hands-on oriented complement to the reference documentation presented here.
Architecture overview
IPython engine
The IPython engine is a Python instance that takes Python commands over a network connection. Eventually,
the IPython engine will be a full IPython interpreter, but for now, it is a regular Python interpreter. The engine
can also handle incoming and outgoing Python objects sent over a network connection. When multiple
engines are started, parallel and distributed computing becomes possible. An important feature of an IPython
engine is that it blocks while user code is being executed. Read on for how the IPython controller solves
this problem to expose a clean asynchronous API to the user.
IPython controller
The IPython controller processes provide an interface for working with a set of engines. At a general level,
the controller is a collection of processes to which IPython engines and clients can connect. The controller
is composed of a Hub and a collection of Schedulers. These Schedulers are typically run in separate
processes but on the same machine as the Hub, but can be run anywhere from local threads or on remote
machines.
The controller also provides a single point of contact for users who wish to utilize the engines connected
to the controller. There are different ways of working with a controller. In IPython, all of these models
are implemented via the View.apply() method, after constructing View objects to represent subsets of
engines. The two primary models for interacting with engines are:
• A Direct interface, where engines are addressed explicitly.
• A LoadBalanced interface, where the Scheduler is trusted with assigning work to appropriate en-
gines.
Advanced users can readily extend the View models to enable other styles of parallelism.
Note: A single controller and set of engines can be used with multiple models simultaneously. This opens
The Hub
The center of an IPython cluster is the Hub. This is the process that keeps track of engine connections,
schedulers, clients, as well as all task requests and results. The primary role of the Hub is to facilitate queries
of the cluster state, and minimize the necessary information required to establish the many connections
involved in connecting new clients and engines.
Schedulers
All actions that can be performed on the engine go through a Scheduler. While the engines themselves block
when user code is run, the schedulers hide that from the user to provide a fully asynchronous interface to a
set of engines.
There is one primary object, the Client, for connecting to a cluster. For each execution model, there is a
corresponding View. These views allow users to interact with a set of engines through the interface. Here
are the two default views:
• The DirectView class for explicit addressing.
• The LoadBalancedView class for destination-agnostic scheduling.
Security
IPython uses ZeroMQ for networking, which has provided many advantages, but one of the setbacks is its
utter lack of security [ZeroMQ]. By default, no IPython connections are encrypted, but open ports only
listen on localhost. The only source of security for IPython is via ssh-tunnel. IPython supports both shell
(openssh) and paramiko based tunnels for connections. There is a key necessary to submit requests,
but due to the lack of encryption, it does not provide significant security if loopback traffic is compromised.
In our architecture, the controller is the only process that listens on network ports, and is thus the main
point of vulnerability. The standard model for secure connections is to designate that the controller listen on
localhost, and use ssh-tunnels to connect clients and/or engines.
To connect and authenticate to the controller an engine or client needs some information that the controller
has stored in a JSON file. Thus, the JSON files need to be copied to a location where the clients and engines
can find them. Typically, this is the ~/.ipython/profile_default/security directory on the
host where the client/engine is running (which could be a different host than the controller). Once the JSON
files are copied over, everything should work fine.
Currently, there are two JSON files that the controller creates:
ipcontroller-engine.json This JSON file has the information necessary for an engine to connect to a con-
troller.
ipcontroller-client.json The client’s connection information. This may not differ from the engine’s, but
since the controller may listen on different ports for clients and engines, it is stored separately.
ipcontroller-client.json will look something like this, under default localhost circumstances:
{
"url":"tcp:\/\/127.0.0.1:54424",
"exec_key":"a361fe89-92fc-4762-9767-e2f0a05e3130",
"ssh":"",
"location":"10.19.1.135"
}
If, however, you are running the controller on a work node on a cluster, you will likely need to use ssh
tunnels to connect clients from your laptop to it. You will also probably need to instruct the controller to
listen for engines coming from other work nodes on the cluster. An example of ipcontroller-client.json, as
created by:
{
"url":"tcp:\/\/*:54424",
"exec_key":"a361fe89-92fc-4762-9767-e2f0a05e3130",
"ssh":"login.mycluster.com",
"location":"10.0.0.2"
}
More details of how these JSON files are used are given below.
A detailed description of the security model and its implementation in IPython can be found here.
Warning: Even at its most secure, the Controller listens on ports on localhost, and every time you make
a tunnel, you open a localhost port on the connecting machine that points to the Controller. If localhost
on the Controller’s machine, or the machine of any client or engine, is untrusted, then your Controller is
insecure. There is no way around this with ZeroMQ.
Getting Started
To use IPython for parallel computing, you need to start one instance of the controller and one or more
instances of the engine. Initially, it is best to simply start a controller and engines on a single host using the
ipcluster command. To start a controller and 4 engines on your localhost, just do:
$ ipcluster start -n 4
More details about starting the IPython controller and engines can be found here
Once you have started the IPython controller and one or more engines, you are ready to use the engines to
do something useful. To make sure everything is working correctly, try the following commands:
In [2]: c = Client()
In [4]: c.ids
Out[4]: set([0, 1, 2, 3])
When a client is created with no arguments, the client tries to find the corresponding JSON file in the local
~/.ipython/profile_default/security directory. Or if you specified a profile, you can use
that with the Client. This should cover most cases:
In [2]: c = Client(profile='myprofile')
If you have put the JSON file in a different location or it has a different name, create the client like this:
In [2]: c = Client('/path/to/my/ipcontroller-client.json')
Remember, a client needs to be able to see the Hub’s ports to connect. So if they are on a different machine,
you may need to use an ssh server to tunnel access to that machine, then you would connect to it with:
Where ‘myhub.example.com’ is the url or IP address of the machine on which the Hub process is running
(or another machine that has direct access to the Hub’s ports).
The SSH server may already be specified in ipcontroller-client.json, if the controller was instructed at its
launch time.
You are now ready to learn more about the Direct and LoadBalanced interfaces to the controller.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
To use IPython for parallel computing, you need to start one instance of the controller and one or more
instances of the engine. The controller and each engine can run on different machines or on the same
machine. Because of this, there are many different possibilities.
Broadly speaking, there are two ways of going about starting a controller and engines:
• In an automated manner using the ipcluster command.
• In a more manual way using the ipcontroller and ipengine commands.
This document describes both of these methods. We recommend that new users start with the ipcluster
command as it simplifies many common usage cases.
General considerations
Before delving into the details about how you can start a controller and engines using the various methods,
we outline some of the general issues that come up when starting the controller and engines. These things
come up no matter which method you use to start your IPython cluster.
If you are running engines on multiple machines, you will likely need to instruct the controller to listen for
connections on an external interface. This can be done by specifying the ip argument on the command-line,
or the HubFactory.ip configurable in ipcontroller_config.py.
If your machines are on a trusted network, you can safely instruct the controller to listen on all interfaces
with:
Or you can set the same behavior as the default by adding the following line to your
ipcontroller_config.py:
c.HubFactory.ip = '*'
# c.HubFactory.location = '10.0.1.1'
Note: --ip=* instructs ZeroMQ to listen on all interfaces, but it does not contain the IP needed for engines
/ clients to know where the controller actually is. This can be specified with --location=10.0.0.1,
the specific IP address of the controller, as seen from engines and/or clients. IPython tries to guess this value
by default, but it will not always guess correctly. Check the location field in your connection files if you
are having connection trouble.
Note: Due to the lack of security in ZeroMQ, the controller will only listen for connections on localhost
by default. If you see Timeout errors on engines or clients, then the first thing you should check is the ip
address the controller is listening on, and make sure that it is visible from the timing out machine.
See also:
Our notes on security in the new parallel computing code.
Let’s say that you want to start the controller on host0 and engines on hosts host1-hostn. The following
steps are then required:
1. Start the controller on host0 by running ipcontroller on host0. The controller must be
instructed to listen on an interface visible to the engine machines, via the ip command-line argument
or HubFactory.ip in ipcontroller_config.py.
2. Move the JSON file (ipcontroller-engine.json) created by the controller from host0 to
hosts host1-hostn.
3. Start the engines on hosts host1-hostn by running ipengine. This command has to be told
where the JSON file (ipcontroller-engine.json) is located.
At this point, the controller and engines will be connected. By default, the JSON files created by the con-
troller are put into the IPYTHONDIR/profile_default/security directory. If the engines share a
filesystem with the controller, step 2 can be skipped as the engines will automatically look at that location.
The final step required to actually use the running controller from a client is to move the JSON file
ipcontroller-client.json from host0 to any host where clients will be run. If these file are
put into the IPYTHONDIR/profile_default/security directory of the client’s host, they will be
found automatically. Otherwise, the full path to them has to be passed to the client’s constructor.
Using ipcluster
The ipcluster command provides a simple way of starting a controller and engines in the following
situations:
1. When the controller and engines are all run on localhost. This is useful for testing or running on a
multicore computer.
2. When engines are started using the mpiexec command that comes with most MPI [MPI] implemen-
tations
3. When engines are started using the PBS [PBS] batch system (or other qsub systems, such as SGE).
4. When the controller is started on localhost and the engines are started on remote nodes using ssh.
5. When engines are started using the Windows HPC Server batch system.
Under the hood, ipcluster just uses ipcontroller and ipengine to perform the steps described
above.
The simplest way to use ipcluster requires no configuration, and will launch a controller and a number of
engines on the local machine. For instance, to start one controller and 4 engines on localhost, just do:
$ ipcluster start -n 4
$ ipcluster -h
Cluster configurations are stored as profiles. You can create a new profile with:
This will create the directory IPYTHONDIR/profile_myprofile, and populate it with the default
configuration files for the three IPython cluster commands. Once you edit those files, you can continue to call
ipcluster/ipcontroller/ipengine with no arguments beyond profile=myprofile, and any configuration
will be maintained.
There is no limit to the number of profiles you can have, so you can maintain a profile for each of your
common use cases. The default profile will be used whenever the profile argument is not specified, so edit
IPYTHONDIR/profile_default/*_config.py to represent your most common use case.
The configuration files are loaded with commented-out settings and explanations, which should cover most
of the available possibilities.
ipcluster has a notion of Launchers that can start controllers and engines with various remote execu-
tion schemes. Currently supported models include ssh, mpiexec, PBS-style (Torque, SGE, LSF), and
Windows HPC Server.
In general, these are configured by the IPClusterEngines.engine_set_launcher_class, and
IPClusterStart.controller_launcher_class configurables, which can be the fully specified
object name (e.g. 'IPython.parallel.apps.launcher.LocalControllerLauncher'), but
if you are using IPython’s builtin launchers, you can specify just the class name, or even just the prefix e.g:
c.IPClusterEngines.engine_launcher_class = 'SSH'
# equivalent to
c.IPClusterEngines.engine_launcher_class = 'SSHEngineSetLauncher'
# both of which expand to
c.IPClusterEngines.engine_launcher_class = 'IPython.parallel.apps.launcher.
˓→SSHEngineSetLauncher'
The shortest form being of particular use on the command line, where all you need to do to get an IPython
cluster running with engines started with MPI is:
Note: shortcuts for builtin launcher names were added in 0.12, as was the _class suffix on the config-
urable names. If you use the old 0.11 names (e.g. engine_set_launcher), they will still work, but you
will get a deprecation warning that the name has changed.
Note: The Launchers and configuration are designed in such a way that advanced users can subclass and
configure them to fit their own system that we have not yet supported (such as Condor)
c.IPClusterEngines.engine_launcher_class = 'MPIEngineSetLauncher'
If the default MPI configuration is correct, then you can now start your cluster, with:
c.IPClusterStart.controller_launcher_class = 'MPIControllerLauncher'
Note: The Controller will not be in the same MPI universe as the engines, so there is not much reason to
do this unless sysadmins demand it.
On newer MPI implementations (such as OpenMPI), this will work even if you don’t make any calls to
MPI or call MPI_Init(). However, older MPI implementations actually require each process to call
MPI_Init() upon starting. The easiest way of having this done is to install the mpi4py [mpi4py] package
and then specify the c.MPI.use option in ipengine_config.py:
c.MPI.use = 'mpi4py'
Unfortunately, even this won’t work for some MPI implementations. If you are having problems with this,
you will likely have to use a custom Python executable that itself calls MPI_Init() at the appropriate
time. Fortunately, mpi4py comes with such a custom Python executable that is easy to install and use.
However, this custom Python executable approach will not work with ipcluster currently.
More details on using MPI with IPython can be found here.
The PBS mode uses the Portable Batch System (PBS) to start the engines.
As usual, we will start by creating a fresh profile:
And in ipcluster_config.py, we will select the PBS launchers for the controller and engines:
c.IPClusterStart.controller_launcher_class = 'PBSControllerLauncher'
c.IPClusterEngines.engine_launcher_class = 'PBSEngineSetLauncher'
Note: Note that the configurable is IPClusterEngines for the engine launcher, and IPClusterStart for the
controller launcher. This is because the start command is a subclass of the engine command, adding a
controller launcher. Since it is a subclass, any configuration made in IPClusterEngines is inherited by
IPClusterStart unless it is overridden.
IPython does provide simple default batch templates for PBS and SGE, but you may need to specify your
own. Here is a sample PBS script template:
#PBS -N ipython
#PBS -j oe
#PBS -l walltime=00:10:00
#PBS -l nodes={n/4}:ppn=4
#PBS -q {queue}
cd $PBS_O_WORKDIR
export PATH=$HOME/usr/local/bin
export PYTHONPATH=$HOME/usr/local/lib/python2.7/site-packages
/usr/local/bin/mpiexec -n {n} ipengine --profile-dir={profile_dir}
#PBS -N ipython
#PBS -j oe
#PBS -l walltime=00:10:00
#PBS -l nodes=1:ppn=4
#PBS -q {queue}
cd $PBS_O_WORKDIR
export PATH=$HOME/usr/local/bin
export PYTHONPATH=$HOME/usr/local/lib/python2.7/site-packages
ipcontroller --profile-dir={profile_dir}
Once you have created these scripts, save them with names like pbs.engine.template. Now you can
load them into the ipcluster_config with:
c.PBSEngineSetLauncher.batch_template_file = "pbs.engine.template"
c.PBSControllerLauncher.batch_template_file = "pbs.controller.template"
Alternately, you can just define the templates as strings inside ipcluster_config.
Whether you are using your own templates or our defaults, the extra configurables available are the number
of engines to launch ({n}, and the batch system queue to which the jobs are to be submitted ({queue})).
These are configurables, and can be specified in ipcluster_config:
c.PBSLauncher.queue = 'veryshort.q'
c.IPClusterEngines.n = 64
Note that assuming you are running PBS on a multi-node cluster, the Controller’s default behavior of lis-
tening only on localhost is likely too restrictive. In this case, also assuming the nodes are safely behind a
firewall, you can simply instruct the Controller to listen for connections on all its interfaces, by adding in
ipcontroller_config:
c.HubFactory.ip = '*'
Note: Due to the flexibility of configuration, the PBS launchers work with simple changes to the template
for other qsub-using systems, such as Sun Grid Engine, and with further configuration in similar batch
systems like Condor.
The SSH mode uses ssh to execute ipengine on remote nodes and ipcontroller can be run remotely
as well, or on localhost.
Note: When using this mode it highly recommended that you have set up SSH keys and are using ssh-agent
[SSH] for password-less logins.
c.IPClusterEngines.engine_launcher_class = 'SSHEngineSetLauncher'
# and if the Controller is also to be remote:
c.IPClusterStart.controller_launcher_class = 'SSHControllerLauncher'
Engines are specified in a dictionary, by hostname and the number of engines to be run on that host.
c.SSHEngineSetLauncher.engines = { 'host1.example.com' : 2,
'host2.example.com' : 5,
'host3.example.com' : (1, ['--profile-dir=/home/different/location
˓→']),
'host4.example.com' : 8 }
• The engines dict, where the keys are the host we want to run engines on and the value is the number
of engines to run on that host.
• on host3, the value is a tuple, where the number of engines is first, and the arguments to be passed to
ipengine are the second element.
For engines without explicitly specified arguments, the default arguments are set in a single location:
c.SSHEngineSetLauncher.engine_args = ['--profile-dir=/path/to/profile_ssh']
SSH launchers will try to move connection files, controlled by the to_send and to_fetch configurables.
If your machines are on a shared filesystem, this step is unnecessary, and can be skipped by setting these to
empty lists:
c.SSHLauncher.to_send = []
c.SSHLauncher.to_fetch = []
If our default guesses about paths don’t work for you, or other files should be moved, you can manually
specify these lists as tuples of (local_path, remote_path) for to_send, and (remote_path, local_path) for
to_fetch. If you do specify these lists explicitly, IPython will not automatically send connection files, so you
must include this yourself if they should still be sent/retrieved.
The excellent StarCluster toolkit for managing Amazon EC2 clusters has a plugin which makes deploying
IPython on EC2 quite simple. The starcluster plugin uses ipcluster with the SGE launchers to distribute
engines across the EC2 cluster. See their ipcluster plugin documentation for more information.
It is also possible to use the ipcontroller and ipengine commands to start your controller and
engines. This approach gives you full control over all aspects of the startup process.
To use ipcontroller and ipengine to start things on your local machine, do the following.
First start the controller:
$ ipcontroller
Next, start however many instances of the engine you want using (repeatedly) the command:
$ ipengine
The engines should start and automatically connect to the controller using the JSON files in IPYTHONDIR/
profile_default/security. You are now ready to use the controller and engines from IPython.
Warning: The order of the above operations may be important. You must start the controller before the
engines, unless you are reusing connection information (via --reuse), in which case ordering is not
important.
Note: On some platforms (OS X), to put the controller and engine into the background you may need to
give these commands in the form (ipcontroller &) and (ipengine &) (with the parentheses) for
them to work properly.
When the controller and engines are running on different hosts, things are slightly more complicated, but
the underlying ideas are the same:
1. Start the controller on a host using ipcontroller. The controller must be instructed to listen on
an interface visible to the engine machines, via the ip command-line argument or HubFactory.ip
in ipcontroller_config.py:
$ ipcontroller --ip=192.168.1.16
# in ipcontroller_config.py
HubFactory.ip = '192.168.1.16'
$ ipengine --file=/path/to/my/ipcontroller-engine.json
Note: If the controller’s and engine’s hosts all have a shared file system (IPYTHONDIR/
profile_<name>/security is the same on all of them), then things will just work!
SSH Tunnels
If your engines are not on the same LAN as the controller, or you are on a highly restricted network where
your nodes cannot see each others ports, then you can use SSH tunnels to connect engines to the controller.
Note: This does not work in all cases. Manual tunnels may be an option, but are highly inconvenient.
You can instruct all engines to use ssh, by specifying the ssh server in ipcontroller-engine.json:
{
"url":"tcp://192.168.1.123:56951",
"exec_key":"26f4c040-587d-4a4e-b58b-030b96399584",
"ssh":"[email protected]",
"location":"192.168.1.123"
}
This will be specified if you give the [email protected] argument when starting
ipcontroller.
Or you can specify an ssh server on the command-line when starting an engine:
For example, if your system is totally restricted, then all connections will actually be loopback, and ssh
tunnels will be used to connect engines to the controller:
Or if you want to start many engines on each node, the command ipcluster engines --n=4 without
any configuration is equivalent to running ipengine 4 times.
No configuration files are necessary to use ipcontroller/engine in an SSH environment without a shared
filesystem. You simply need to make sure that the controller is listening on an interface visible to the
engines, and move the connection file from the controller to the engines.
1. start the controller, listening on an ip-address visible to the engine machines:
Note: The log output of ipcontroller above shows you where the json files were written. They will
be in ~/.ipython under profile_default/security/ipcontroller-engine.json
A couple of notes:
• You can avoid having to fetch the connection file every time by adding --reuse flag to ipcontroller,
which instructs the controller to read the previous connection file for connection info, rather than
generate a new one with randomized ports.
• In step 2, if you fetch the connection file directly into the security dir of a profile, then you need not
specify its path directly, only the profile (assumes the path exists, otherwise you must create it first):
Of course, if you fetch the file into the default profile, no arguments must be passed to ipengine at all.
• Note that ipengine did not specify the ip argument. In general, it is unlikely for any connection
information to be specified at the command-line to ipengine, as all of this information should be
contained in the connection file written by ipcontroller.
At fist glance it may seem that that managing the JSON files is a bit annoying. Going back to the house and
key analogy, copying the JSON around each time you start the controller is like having to make a new key
every time you want to unlock the door and enter your house. As with your house, you want to be able to
create the key (or JSON file) once, and then simply use it at any point in the future.
To do this, the only thing you have to do is specify the --reuse flag, so that the connection information in
the JSON files remains accurate:
$ ipcontroller --reuse
Then, just copy the JSON files over the first time and you are set. You can start and stop the controller and
engines any many times as you want in the future, just make sure to tell the controller to reuse the file.
Note: You may ask the question: what ports does the controller listen on if you don’t tell is to use specific
ones? The default is to use high random port numbers. We do this for two reasons: i) to increase security
through obscurity and ii) to multiple controllers on a given host to start and automatically use different ports.
Log files
All of the components of IPython have log files associated with them. These log files can be ex-
tremely useful in debugging problems with IPython and can be found in the directory IPYTHONDIR/
profile_<name>/log. Sending the log files to us will often help us to debug any problems.
Configuring ipcontroller
The IPython Controller takes its configuration from the file ipcontroller_config.py in the active
profile directory.
In many cases, you will want to configure the Controller’s network identity. By default, the Controller listens
only on loopback, which is the most secure but often impractical. To instruct the controller to listen on a
specific interface, you can set the HubFactory.ip trait. To listen on all interfaces, simply specify:
c.HubFactory.ip = '*'
When connecting to a Controller that is listening on loopback or behind a firewall, it may be necessary to
specify an SSH server to use for tunnels, and the external IP of the Controller. If you specified that the
HubFactory listen on loopback, or all interfaces, then IPython will try to guess the external IP. If you are on
a system with VM network devices, or many interfaces, this guess may be incorrect. In these cases, you will
want to specify the ‘location’ of the Controller. This is the IP of the machine the Controller is on, as seen by
the clients, engines, or the SSH server used to tunnel connections.
For example, to set up a cluster with a Controller on a work node, using ssh tunnels through the login node,
an example ipcontroller_config.py might contain:
# you typically only need to specify the location when there are extra
# interfaces that may not be visible to peer nodes (e.g. VM interfaces)
c.HubFactory.location = '10.0.1.5'
# or to get an automatic value, try this:
import socket
hostname = socket.gethostname()
# alternate choices for hostname include `socket.getfqdn()`
# or `socket.gethostname() + '.local'`
ex_ip = socket.gethostbyname_ex(hostname)[-1][-1]
c.HubFactory.location = ex_ip
# now instruct clients to use the login node for SSH tunnels:
c.HubFactory.ssh_server = 'login.mycluster.net'
After doing this, your ipcontroller-client.json file will look something like this:
{
"url":"tcp:\/\/*:43447",
"exec_key":"9c7779e4-d08a-4c3b-ba8e-db1f80b562c1",
"ssh":"login.mycluster.net",
"location":"10.0.1.5"
}
Then this file will be all you need for a client to connect to the controller, tunneling SSH connections through
login.mycluster.net.
Database Backend
The Hub stores all messages and results passed between Clients and Engines. For large and/or long-running
clusters, it would be unreasonable to keep all of this information in memory. For this reason, we have two
database backends: [MongoDB] via PyMongo, and SQLite with the stdlib sqlite.
MongoDB is our design target, and the dict-like model it uses has driven our design. As far as we are
concerned, BSON can be considered essentially the same as JSON, adding support for binary data and
datetime objects, and any new database backend must support the same data types.
See also:
MongoDB BSON doc
To use one of these backends, you must set the HubFactory.db_class trait:
# To use MongoDB:
c.HubFactory.db_class = 'IPython.parallel.controller.mongodb.MongoDB'
# and SQLite:
c.HubFactory.db_class = 'IPython.parallel.controller.sqlitedb.SQLiteDB'
# You can use NoDB to disable the database altogether, in case you don't need
# to reuse tasks or results, and want to keep memory consumption under
˓→control.
c.HubFactory.db_class = 'IPython.parallel.controller.dictdb.NoDB'
When using the proper databases, you can actually allow for tasks to persist from one session to the next by
specifying the MongoDB database or SQLite table in which tasks are to be stored. The default is to use a
table named for the Hub’s Session, which is a UUID, and thus different every time.
# To keep persistent task history in MongoDB:
c.MongoDB.database = 'tasks'
# and in SQLite:
c.SQLiteDB.table = 'tasks'
Since MongoDB servers can be running remotely or configured to listen on a particular port, you can specify
any arguments you may need to the PyMongo Connection:
# positional args to pymongo.Connection
c.MongoDB.connection_args = []
But sometimes you are moving lots of data around quickly, and you don’t need that information to be stored
for later access, even by other Clients to this same session. For this case, we have a dummy database, which
doesn’t actually store anything. This lets the Hub stay small in memory, at the obvious expense of being able
to access the information that would have been stored in the database (used for task resubmission, requesting
results of tasks you didn’t submit, etc.). To use this backend, simply pass --nodb to ipcontroller on
the command-line, or specify the NoDB class in your ipcontroller_config.py as described above.
See also:
For more information on the database backends, see the db backend reference.
Configuring ipengine
The IPython Engine takes its configuration from the file ipengine_config.py
The Engine itself also has some amount of configuration. Most of this has to do with initializing MPI or
connecting to the controller.
To instruct the Engine to initialize with an MPI environment set up by mpi4py, add:
c.MPI.use = 'mpi4py'
In this case, the Engine will use our default mpi4py init script to set up the MPI environment prior to
execution. We have default init scripts for mpi4py and pytrilinos. If you want to specify your own code to
be run at the beginning, specify c.MPI.init_script.
You can also specify a file or python command to be run at startup of the Engine:
c.IPEngineApp.startup_script = u'/path/to/my/startup.py'
c.IPEngineApp.work_dir = u'/path/to/scratch/'
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
The direct, or multiengine, interface represents one possible way of working with a set of IPython engines.
The basic idea behind the multiengine interface is that the capabilities of each engine are directly and ex-
plicitly exposed to the user. Thus, in the multiengine interface, each engine is given an id that is used to
identify the engine and give it work to do. This interface is very intuitive and is designed with interactive
usage in mind, and is the best place for new users of IPython to begin.
To follow along with this tutorial, you will need to start the IPython controller and four IPython engines.
The simplest way of doing this is to use the ipcluster command:
$ ipcluster start -n 4
For more detailed information about starting the controller and engines, see our introduction to using IPython
for parallel computing.
The first step is to import the IPython IPython.parallel module and then create a Client instance:
In [2]: rc = Client()
This form assumes that the default connection information (stored in ipcontroller-client.json
found in IPYTHONDIR/profile_default/security) is accurate. If the controller was started on a
remote machine, you must copy that connection file to the client machine, or enter its contents as arguments
to the Client constructor:
# If you have copied the json connector file from the controller:
In [2]: rc = Client('/path/to/ipcontroller-client.json')
# or to connect with a specific profile you have set up:
In [3]: rc = Client(profile='mpi')
To make sure there are engines connected to the controller, users can get a list of engine ids:
In [3]: rc.ids
Out[3]: [0, 1, 2, 3]
Here we see that there are four engines ready to do work for us.
For direct execution, we will make use of a DirectView object, which can be constructed via list-access
to the client:
See also:
For more information, see the in-depth explanation of Views.
In many cases, you simply want to apply a Python function to a sequence of objects, but in parallel. The
client interface provides a simple way of accomplishing this: using the DirectView’s map() method.
Parallel map
Python’s builtin map() functions allows a function to be applied to a sequence element-by-element. This
type of code is typically trivial to parallelize. In fact, since IPython’s interface is all about functions anyway,
you can just use the builtin map() with a RemoteFunction, or a DirectView’s map() method:
In [67]: serial_result==parallel_result
Out[67]: True
Note: The DirectView‘s version of map() does not do dynamic load balancing. For a load balanced
version, use a LoadBalancedView.
See also:
map() is implemented via ParallelFunction.
Remote functions are just like normal functions, but when they are called, they execute on one or more
engines, rather than locally. IPython provides two decorators:
In [10]: @dview.remote(block=True)
....: def getpid():
....: import os
In [11]: getpid()
Out[11]: [12345, 12346, 12347, 12348]
The @parallel decorator creates parallel functions, that break up an element-wise operations and dis-
tribute them, reconstructing the result.
In [13]: A = np.random.random((64,48))
In [14]: @dview.parallel(block=True)
....: def pmul(A,B):
....: return A*B
Calling a @parallel function does not correspond to map. It is used for splitting element-wise operations
that operate on a sequence or array. For map behavior, parallel functions do have a map method.
call pfunc(seq) pfunc.map(seq)
# of tasks # of engines (1 per engine) # of engines (1 per engine)
# of remote calls # of engines (1 per engine) len(seq)
argument to remote seq[i:j] (sub-sequence) seq[i] (single element)
A quick example to illustrate the difference in arguments for the two modes:
In [16]: @dview.parallel(block=True)
....: def echo(x):
....: return str(x)
....:
In [17]: echo(range(5))
Out[17]: ['[0, 1]', '[2]', '[3]', '[4]']
In [18]: echo.map(range(5))
Out[18]: ['0', '1', '2', '3', '4']
See also:
See the parallel() and remote() decorators for options.
The most basic type of operation that can be performed on the engines is to execute Python code or call
Python functions. Executing Python code can be done in blocking or non-blocking mode (non-blocking is
default) using the View.execute() method, and calling functions can be done via the View.apply()
method.
apply
The main method for doing remote execution (in fact, all methods that communicate with the engines are
built on top of it), is View.apply().
We strive to provide the cleanest interface we can, so apply has the following signature:
There are various ways to call functions with IPython, and these flags are set as attributes of the View. The
DirectView has just two of these flags:
dv.block [bool] whether to wait for the result, or return an AsyncResult object immediately
dv.track [bool] whether to instruct pyzmq to track when zeromq is done sending the message. This is
primarily useful for non-copying sends of numpy arrays that you plan to edit in-place. You need to
know when it becomes safe to edit the buffer without corrupting the message.
dv.targets [int, list of ints] which targets this view is associated with.
Creating a view is simple: index-access on a client creates a DirectView.
In [5]: view.apply<tab>
view.apply view.apply_async view.apply_sync
For convenience, you can set block temporarily for a single call with the extra sync/async methods.
Blocking execution
In blocking mode, the DirectView object (called dview in these examples) submits the command to the
controller, which places the command in the engines’ queues for execution. The apply() call then blocks
until the engines are done executing the command:
In [5]: dview['b'] = 10
You can also select blocking execution on a call-by-call basis with the apply_sync() method:
In [7]: dview.block=False
Python commands can be executed as strings on specific engines by using a View’s execute method:
In [6]: rc[::2].execute('c=a+b')
In [7]: rc[1::2].execute('c=a-b')
Non-blocking execution
In non-blocking mode, apply() submits the command to be executed and then returns a AsyncResult
object immediately. The AsyncResult object gives you a way of getting a result at a later time through
its get() method.
See also:
Docs on the AsyncResult object.
This allows you to quickly submit long running commands without blocking your local Python/IPython
session:
# In non-blocking mode
In [7]: ar = dview.apply_async(wait, 2)
In [45]: ar.get(1)
---------------------------------------------------------------------------
TimeoutError Traceback (most recent call last)
/home/you/<ipython-input-45-7cd858bbb8e0> in <module>()
----> 1 ar.get(1)
Note: Note the import inside the function. This is a common model, to ensure that the appropriate modules
are imported where the task is run. You can also manually import modules into the engine(s) namespace(s)
via view.execute('import numpy')().
Often, it is desirable to wait until a set of AsyncResult objects are done. For this, there is a the method
wait(). This method takes a tuple of AsyncResult objects (or msg_ids or indices to the client’s
History), and blocks until all of the associated results are ready:
In [72]: dview.block=False
# Then, their results are ready using get() or the `.r` attribute
In [75]: pr_list[0].get()
Out[75]: [2.9982571601867676, 2.9982588291168213, 2.9987530708312988, 2.
˓→9990990161895752]
Most DirectView methods (excluding apply()) accept block and targets as keyword arguments. As
we have seen above, these keyword arguments control the blocking mode and which engines the command
is applied to. The View class also has block and targets attributes that control the default behavior
when the keyword arguments are not provided. Thus the following logic is used for block and targets:
• If no keyword argument is provided, the instance attributes are used.
• The Keyword arguments, if provided overrides the instance attributes for the duration of a single call.
The following examples demonstrate how to use the instance attributes:
In [19]: ar.get()
Out[19]: [10, 10]
The block and targets instance attributes of the DirectView also determine the behavior of the
parallel magic commands.
See also:
See the documentation of the Parallel Magics.
In addition to calling functions and executing code on engines, you can transfer Python objects to and from
your IPython session and the engines. In IPython, these operations are called push() (sending an object
to the engines) and pull() (getting an object from the engines).
Here are some examples of how you use push() and pull():
In [38]: dview.push(dict(a=1.03234,b=3453))
Out[38]: [None,None,None,None]
In [39]: dview.pull('a')
Out[39]: [ 1.03234, 1.03234, 1.03234, 1.03234]
In [41]: dview.pull(('a','b'))
Out[41]: [ [1.03234, 3453], [1.03234, 3453], [1.03234, 3453], [1.03234, 3453]
˓→]
In [42]: dview.push(dict(c='speed'))
Out[42]: [None,None,None,None]
In [49]: ar.get()
Out[49]: [1.03234, 1.03234, 1.03234, 1.03234]
Dictionary interface
Since a Python namespace is just a dict, DirectView objects provide dictionary-style access by key
and methods such as get() and update() for convenience. This make the remote namespaces of the
engines appear as a local dictionary. Underneath, these methods call apply():
In [51]: dview['a']=['foo','bar']
In [52]: dview['a']
Out[52]: [ ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'] ]
Sometimes it is useful to partition a sequence and push the partitions to different engines. In MPI lan-
guage, this is know as scatter/gather and we follow that terminology. However, it is important to remember
that in IPython’s Client class, scatter() is from the interactive IPython session to the engines and
gather() is from the engines back to the interactive IPython session. For scatter/gather operations be-
tween engines, MPI, pyzmq, or some other direct interconnect should be used.
In [58]: dview.scatter('a',range(16))
Out[58]: [None,None,None,None]
In [59]: dview['a']
Out[59]: [ [0, 1, 2, 3], [4, 5, 6, 7], [8, 9, 10, 11], [12, 13, 14, 15] ]
In [60]: dview.gather('a')
Out[60]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
In many cases list comprehensions are nicer than using the map function. While we don’t have fully parallel
list comprehensions, it is simple to get the basic effect using scatter() and gather():
In [66]: dview.scatter('x',range(64))
In [68]: y = dview.gather('y')
In [69]: print y
[0, 1, 1024, 59049, 1048576, 9765625, 60466176, 282475249, 1073741824,...]
Remote imports
Sometimes you will want to import packages both in your interactive session and on your remote engines.
This can be done with the ContextManager created by a DirectView’s sync_imports() method:
Any imports made inside the block will also be performed on the view’s engines. sync_imports also takes
a local boolean flag that defaults to True, which specifies whether the local imports should also be per-
formed. However, support for local=False has not been implemented, so only packages that can be
imported locally will work this way.
You can also specify imports via the @require decorator. This is a decorator designed for use in Depen-
dencies, but can be used to handle remote imports as well. Modules or module names passed to @require
will be imported before the decorated function is called. If they cannot be imported, the decorated function
will never execute and will fail with an UnmetDependencyError. Failures of single Engines will be collected
and raise a CompositeError, as demonstrated in the next section.
In [70]: @require('re')
....: def findall(pat, x):
....: # re is guaranteed to be available
....: return re.findall(pat, x)
# you can also pass modules themselves, that you already have locally:
In [71]: @require(time)
....: def wait(t):
....: time.sleep(t)
....: return t
Note: sync_imports() does not allow import foo as bar syntax, because the assignment rep-
resented by the as bar part is not available to the import hook.
Parallel exceptions
In the multiengine interface, parallel commands can raise Python exceptions, just like serial commands. But
it is a little subtle, because a single parallel command can actually raise multiple exceptions (one for each
engine the command was run on). To express this idea, we have a CompositeError exception class that
will be raised in most cases. The CompositeError class is a special type of exception that wraps one or
more other types of exceptions. Here is how it works:
In [79]: dview.execute("1/0")
[0:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
[1:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
[2:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
[3:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
Notice how the error message printed when CompositeError is raised has information about the indi-
vidual exceptions that were raised on each engine. If you want, you can even raise one of these original
exceptions:
In [80]: try:
....: dview.execute('1/0', block=True)
....: except CompositeError, e:
....: e.raise_exception()
....:
....:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
If you are working in IPython, you can simple type %debug after one of these CompositeError excep-
tions is raised, and inspect the exception instance:
In [81]: dview.execute('1/0')
[0:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
[1:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
[2:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
[3:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
In [82]: %debug
> /.../site-packages/IPython/parallel/client/asyncresult.py(125)get()
124 else:
--> 125 raise self._exception
126 else:
ipdb> e = self._exception
ipdb> e
CompositeError(4)
Since you might have 100 engines, you probably don’t want to see 100 tracebacks for a simple NameEr-
ror because of a typo. For this reason, CompositeError truncates the list of exceptions it will print to
CompositeError.tb_limit (default is five). You can change this limit to suit your needs with:
All of this same error handling magic even works in non-blocking mode:
In [83]: dview.block=False
In [84]: ar = dview.execute('1/0')
In [85]: ar.get()
[0:execute]:
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
----> 1 1/0
ZeroDivisionError: integer division or modulo by zero
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
We provide a few IPython magic commands that make it a bit more pleasant to execute Python commands on
the engines interactively. These are mainly shortcuts to DirectView.execute() and AsyncResult.
display_outputs() methods respectively.
These magics will automatically become available when you create a Client:
The initially active View will have attributes targets='all', block=True, which is a blocking view
of all engines, evaluated at request time (adding/removing engines will change where this view’s tasks will
run).
The Magics
%px
The %px magic executes a single Python command on the engines specified by the targets attribute of
the DirectView instance:
Since engines are IPython as well, you can even run magics remotely:
And once in pylab mode with the inline backend, you can make plots and they will be displayed in your
frontend if it supports the inline figures (e.g. notebook or qtconsole):
%%px can be used as a Cell Magic, which accepts some arguments for controlling the execution.
%%px accepts --targets for controlling which engines on which to run, and --[no]block for speci-
fying the blocking behavior of this cell, independent of the defaults for the View.
In [8]: %%px
...: print "still 'all' by default"
...:
Parallel execution on engine(s): all
[stdout:0] still 'all' by default
[stdout:1] still 'all' by default
[stdout:2] still 'all' by default
[stdout:3] still 'all' by default
In [10]: %pxresult
Out[0:12]: 1339454561.069116
Out[1:10]: 1339454561.076752
Out[2:12]: 1339454561.072837
Out[3:10]: 1339454561.066665
See also:
%pxconfig accepts these same arguments for changing the default values of targets/blocking for the active
View.
Output Display
%%px also accepts a --group-outputs argument, which adjusts how the outputs of multiple engines
are presented.
See also:
AsyncResult.display_outputs() for the grouping options.
%pxresult
If you are using %px in non-blocking mode, you won’t get output. You can use %pxresult to display the
outputs of the latest command, just as is done when %px is blocking:
In [41]: %pxresult
[stdout:0] hi
[stdout:1] hi
[stdout:2] hi
[stdout:3] hi
%autopx
The %autopx magic switches to a mode where everything you type is executed on the engines until you do
%autopx again.
In [30]: dv.block=True
In [31]: %autopx
%autopx enabled
In [32]: max_evals = []
In [35]: %autopx
Auto Parallel Disabled
%pxconfig
The default targets and blocking behavior for the magics are governed by the block and targets attribute
of the active View. If you have a handle for the view, you can set these attributes directly, but if you don’t,
you can change them with the %pxconfig magic:
In [10]: %pxresult
[stdout:0] are you there?
[stdout:2] are you there?
The parallel magics are associated with a particular DirectView object. You can change the active view
by calling the activate() method on any view.
In [12]: even.activate()
When activating a View, you can also specify a suffix, so that a whole different set of magics are associated
with that view, without replacing the existing ones.
In [17]: even.activate('_even')
This suffix is applied to the end of all magics, e.g. %autopx_even, %pxresult_even, etc.
For convenience, the Client has a activate() method as well, which creates a DirectView with
block=True, activates it, and returns the new View.
The initial magics registered when you create a client are the result of a call to rc.activate() with
default args.
Engines as Kernels
Engines are really the same object as the Kernels used elsewhere in IPython, with the minor exception that
engines connect to a controller, while regular kernels bind their sockets, listening for connections from a
QtConsole or other frontends.
Sometimes for debugging or inspection purposes, you would like a QtConsole connected to an engine for
more direct interaction. You can do this by first instructing the Engine to also bind its kernel, to listen for
connections:
Then, if your engines are local, you can start a qtconsole right on the engine(s):
Careful with this one, because if your view is of 16 engines it will start 16 QtConsoles!
Or you can view just the connection info, and work out the right way to connect to the engines, depending
on where they live and where you are:
Note: %qtconsole will call bind_kernel() on an engine if it hasn’t been done already, so you can
often skip that first step.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
The task interface to the cluster presents the engines as a fault tolerant, dynamic load-balanced system of
workers. Unlike the multiengine interface, in the task interface the user have no direct access to individual
engines. By allowing the IPython scheduler to assign work, this interface is simultaneously simpler and
more powerful.
Best of all, the user can use both of these interfaces running at the same time to take advantage of their
respective strengths. When the user can break up the user’s work into segments that do not depend on
previous execution, the task interface is ideal. But it also has more power and flexibility, allowing the user
to guide the distribution of jobs, without having to assign tasks to engines explicitly.
To follow along with this tutorial, you will need to start the IPython controller and four IPython engines.
The simplest way of doing this is to use the ipcluster command:
$ ipcluster start -n 4
For more detailed information about starting the controller and engines, see our introduction to using IPython
for parallel computing.
The first step is to import the IPython IPython.parallel module and then create a Client instance,
and we will also be using a LoadBalancedView, here called lview:
In [2]: rc = Client()
This form assumes that the controller was started on localhost with default configuration. If not, the location
of the controller must be given as an argument to the constructor:
For load-balanced execution, we will make use of a LoadBalancedView object, which can be con-
structed via the client’s load_balanced_view() method:
See also:
For more information, see the in-depth explanation of Views.
In many cases, you simply want to apply a Python function to a sequence of objects, but in parallel. Like
the multiengine interface, these can be implemented via the task interface. The exact same tools can per-
form these actions in load-balanced ways as well as multiplexed ways: a parallel version of map() and
@parallel() function decorator. If one specifies the argument balanced=True, then they are dynam-
ically load balanced. Thus, if the execution time per item varies significantly, you should use the versions in
the task interface.
Parallel map
In [65]: serial_result==parallel_result
Out[65]: True
Parallel functions are just like normal function, but they can be called on sequences and in parallel. The
multiengine interface provides a decorator that turns any Python function into a parallel function:
In [10]: @lview.parallel()
....: def f(x):
....: return 10.0*x**4
....:
Dependencies
Often, pure atomic load-balancing is too primitive for your work. In these cases, you may want to associate
some kind of Dependency that describes when, where, or whether a task can be run. In IPython, we
provide two types of dependencies: Functional Dependencies and Graph Dependencies
Note: It is important to note that the pure ZeroMQ scheduler does not support dependencies, and you will
see errors or warnings if you try to use dependencies with the pure scheduler.
Functional Dependencies
Functional dependencies are used to determine whether a given engine is capable of running a particular
task. This is implemented via a special Exception class, UnmetDependency, found in IPython.
parallel.error. Its use is very simple: if a task fails with an UnmetDependency exception, then the
scheduler, instead of relaying the error up to the client like any other error, catches the error, and submits the
task to a different engine. This will repeat indefinitely, and a task will never be submitted to a given engine
a second time.
You can manually raise the UnmetDependency yourself, but IPython has provided some decorators for
facilitating this behavior.
There are two decorators and a class used for functional dependencies:
@require
The simplest sort of dependency is requiring that a Python module is available. The @require decorator
lets you define a function that will only run on engines where names you specify are importable:
Now, any time you apply myfunc(), the task will only run on a machine that has numpy and pyzmq
available, and when myfunc() is called, numpy and zmq will be imported.
@depend
The @depend decorator lets you decorate any function with any other function to evaluate the dependency.
The dependency function will be called at the start of the task, and if it returns False, then the dependency
will be considered unmet, and the task will be assigned to another engine. If the dependency returns anything
other than ‘‘False‘‘, the rest of the task will continue.
In this case, any time you apply mactask, it will only run on an OSX machine. @depend is just like
apply, in that it has a @depend(f,*args,**kwargs) signature.
dependents
You don’t have to use the decorators on your tasks, if for instance you may want to run tasks with a single
function but varying dependencies, you can directly construct the dependent object that the decorators
use:
Graph Dependencies
Sometimes you want to restrict the time and/or location to run a given task as a function of the time and/or
location of other tasks. This is implemented via a subclass of set, called a Dependency. A Dependency
is just a set of msg_ids corresponding to tasks, and a few attributes to guide how to decide when the
Dependency has been met.
The switches we provide for interpreting whether a given dependency set has been met:
any|all Whether the dependency is considered met if any of the dependencies are done, or only after all of
them have finished. This is set by a Dependency’s all boolean attribute, which defaults to True.
success [default: True] Whether to consider tasks that succeeded as fulfilling dependencies.
failure [default [False]] Whether to consider tasks that failed as fulfilling dependencies. using
failure=True,success=False is useful for setting up cleanup tasks, to be run only when
tasks have failed.
Sometimes you want to run a task after another, but only if that task succeeded. In this case,
success should be True and failure should be False. However sometimes you may not care
whether the task succeeds, and always want the second task to run, in which case you should use
success=failure=True. The default behavior is to only use successes.
There are other switches for interpretation that are made at the task level. These are specified via keyword
arguments to the client’s apply() method.
after,follow You may want to run a task after a given set of dependencies have been run and/or run it where
another set of dependencies are met. To support this, every task has an after dependency to restrict
time, and a follow dependency to restrict destination.
timeout You may also want to set a time-limit for how long the scheduler should wait before a task’s
dependencies are met. This is done via a timeout, which defaults to 0, which indicates that the task
should never timeout. If the timeout is reached, and the scheduler still hasn’t been able to assign the
task to an engine, the task will fail with a DependencyTimeout.
Note: Dependencies only work within the task scheduler. You cannot instruct a load-balanced task to run
after a job submitted via the MUX interface.
In [14]: client.block=False
See also:
Some parallel workloads can be described as a Directed Acyclic Graph, or DAG. See DAG Dependencies
for an example demonstrating how to use map a NetworkX DAG onto task dependencies.
Impossible Dependencies
The schedulers do perform some analysis on graph dependencies to determine whether they are not possible
to be met. If the scheduler does discover that a dependency cannot be met, then the task will fail with an
ImpossibleDependency error. This way, if the scheduler realized that a task can never be run, it won’t
sit indefinitely in the scheduler clogging the pipeline.
The basic cases that are checked:
• depending on nonexistent messages
• follow dependencies were run on more than one machine and all=True
• any dependencies failed and all=True,success=True,failures=False
• all dependencies failed and all=False,success=True,failure=False
Warning: This analysis has not been proven to be rigorous, so it is likely possible for tasks to become
impossible to run in obscure situations, so a timeout may be a good choice.
Retries
Another flag for tasks is retries. This is an integer, specifying how many times a task should be resub-
mitted after failure. This is useful for tasks that should still run if their engine was shutdown, or may have
some statistical chance of failing. The default is to not retry tasks.
Resubmit
Sometimes you may want to re-run a task. This could be because it failed for some reason, and you have
fixed the error, or because you want to restore the cluster to an interrupted state. For this, the Client has
a rc.resubmit() method. This simply takes one or more msg_ids, and returns an AsyncHubResult
for the result(s). You cannot resubmit a task that is pending - only those that have finished, either successful
or unsuccessful.
Schedulers
There are a variety of valid ways to determine where jobs should be assigned in a load-balancing situation.
In IPython, we support several standard schemes, and even make it easy to define your own. The scheme can
be selected via the scheme argument to ipcontroller, or in the TaskScheduler.schemename
attribute of a controller config object.
The built-in routing schemes:
To select one of these schemes, simply do:
$ ipcontroller --scheme=<schemename>
for instance:
$ ipcontroller --scheme=lru
Requires numpy
Pick two engines at random using the number of outstanding tasks as inverse weights, and use
the one with the lower load.
Greedy Assignment
Tasks can be assigned greedily as they are submitted. If their dependencies are met, they will be assigned
to an engine right away, and multiple tasks can be assigned to an engine at a given time. This limit is set
with the TaskScheduler.hwm (high water mark) configurable in your ipcontroller_config.py
config file, with:
In IPython < 0.13, the default is 0, or no-limit. That is, there is no limit to the number of tasks that can be
outstanding on a given engine. This greatly benefits the latency of execution, because network traffic can
be hidden behind computation. However, this means that workload is assigned without knowledge of how
long each task might take, and can result in poor load-balancing, particularly for submitting a collection
of heterogeneous tasks all at once. You can limit this effect by setting hwm to a positive integer, 1 being
maximum load-balancing (a task will never be waiting if there is an idle engine), and any larger number
being a compromise between load-balancing and latency-hiding.
In practice, some users have been confused by having this optimization on by default, so the default value
has been changed to 1 in IPython 0.13. This can be slower, but has more obvious behavior and won’t result
in assigning too many tasks to some engines in heterogeneous cases.
For maximum throughput, the ‘pure’ scheme is not Python at all, but a C-level MonitoredQueue from
PyZMQ, which uses a ZeroMQ DEALER socket to perform all load-balancing. This scheduler does not
support any of the advanced features of the Python Scheduler.
Disabled features when using the ZMQ Scheduler:
• Engine unregistration Task farming will be disabled if an engine unregisters. Further, if an engine
is unregistered during computation, the scheduler may not recover.
• Dependencies Since there is no Python logic inside the Scheduler, routing decisions cannot be made
based on message content.
• Early destination notification The Python schedulers know which engine gets which task, and no-
tify the Hub. This allows graceful handling of Engines coming and going. There is no way to
know where ZeroMQ messages have gone, so there is no way to know what tasks are on which
engine until they finish. This makes recovery from engine shutdown very difficult.
More details
The LoadBalancedView has many more powerful features that allow quite a bit of flexibility in how
tasks are defined and run. The next places to look are in the following classes:
• LoadBalancedView
• AsyncResult
• apply()
• dependency
The following is an overview of how to use these classes together:
1. Create a Client and LoadBalancedView
2. Define some functions to be run as tasks
3. Submit your tasks to using the apply() method of your LoadBalancedView instance.
4. Use Client.get_result() to get the results of the tasks, or use the AsyncResult.get()
method of the results to wait for and then receive the results.
See also:
A demo of DAG Dependencies with NetworkX and IPython.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
In non-blocking mode, apply() submits the command to be executed and then returns a AsyncResult
object immediately. The AsyncResult object gives you a way of getting a result at a later time through its
get() method, but it also collects metadata on execution.
Our AsyncResult objects add a number of convenient features for working with parallel results, beyond what
is provided by the original AsyncResult.
get_dict
First, is AsyncResult.get_dict(), which pulls results as a dictionary keyed by engine_id, rather than
a flat list. This is useful for quickly coordinating or distributing information about all of the engines.
As an example, here is a quick call that gives every engine a dict showing the PID of every other engine:
In [10]: ar = rc[:].apply_async(os.getpid)
In [11]: pids = ar.get_dict()
In [12]: rc[:]['pid_map'] = pids
This trick is particularly useful when setting up inter-engine communication, as in IPython’s examples/
parallel/interengine examples.
Metadata
IPython.parallel tracks some metadata about the tasks, which is stored in the Client.metadata dict.
The AsyncResult object gives you an interface for this information as well, including timestamps stdout/err,
and engine IDs.
Timing
IPython tracks various timestamps as datetime objects, and the AsyncResult object has a few properties
that turn these into useful times (in seconds as floats).
For use while the tasks are still pending:
• ar.elapsed is just the elapsed seconds since submission, for use before the AsyncResult is com-
plete.
• ar.progress is the number of tasks that have completed. Fractional progress would be:
• AsyncResult.wait_interactive() will wait for the result to finish, but print out status up-
dates on progress and elapsed time while it waits.
For use after the tasks are done:
• ar.serial_time is the sum of the computation time of all of the tasks done in parallel.
• ar.wall_time is the time between the first task submitted and last result received. This is the
actual cost of computation, including IPython overhead.
Note: wall_time is only precise if the Client is waiting for results when the task finished, because the
received timestamp is made when the result is unpacked by the Client, triggered by the spin() call. If
you are doing work in the Client, and not waiting/spinning, then received might be artificially high.
An often interesting metric is the time it actually cost to do the work in parallel relative to the serial compu-
tation, and this can be given simply with
When an AsyncResult object has multiple results (e.g. the AsyncMapResult object), you can actually
iterate through results themselves, and act on them as they arrive:
import time
def sleep_here(t):
import time
time.sleep(t)
return id,t
tic = time.time()
for i,r in enumerate(amr):
print("slept %.2fs on engine %i: %.3f" % (r[1], r[0], time.time()-tic))
That is to say, if you treat an AsyncMapResult as if it were a list of your actual results, it should behave as
you would expect, with the only difference being that you can start iterating through the results before they
have even been computed.
This lets you do a dumb version of map/reduce with the builtin Python functions, and the only difference
between doing this locally and doing it remotely in parallel is using the asynchronous view.map instead of
the builtin map.
Here is a simple one-line RMS (root-mean-square) implemented with Python’s builtin map/reduce.
In [38]: X = np.linspace(0,100)
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Often, a parallel algorithm will require moving data between the engines. One way of accomplishing this is
by doing a pull and then a push using the multiengine client. However, this will be slow as all the data has
to go through the controller to the client and then back through the controller, to its final destination.
A much better way of moving data between engines is to use a message passing library, such as the Mes-
sage Passing Interface (MPI) [MPI]. IPython’s parallel computing architecture has been designed from the
ground up to integrate with MPI. This document describes how to use MPI with IPython.
If you want to use MPI with IPython, you will need to install:
• A standard MPI implementation such as OpenMPI [OpenMPI] or MPICH.
• The mpi4py [mpi4py] package.
Note: The mpi4py package is not a strict requirement. However, you need to have some way of calling
MPI from Python. You also need some way of making sure that MPI_Init() is called when the IPython
engines start up. There are a number of ways of doing this and a good number of associated subtleties. We
highly recommend just using mpi4py as it takes care of most of these problems. If you want to do something
different, let us know and we can help you get started.
To use code that calls MPI, there are typically two things that MPI requires.
1. The process that wants to call MPI must be started using mpiexec or a batch system (like PBS) that
has MPI support.
2. Once the process starts, it must call MPI_Init().
There are a couple of ways that you can start the IPython engines and get these things to happen.
The easiest approach is to use the MPI Launchers in ipcluster, which will first start a controller and
then a set of engines using mpiexec:
This approach is best as interrupting ipcluster will automatically stop and clean up the controller and
engines.
If you want to start the IPython engines using the mpiexec, just do:
This requires that you already have a controller running and that the FURL files for the engines are in place.
We also have built in support for PyTrilinos [PyTrilinos], which can be used (assuming is installed) by
starting the engines with:
The ipcluster command also has built-in integration with PBS. For more information on this approach,
see our documentation on ipcluster.
Once the engines are running with MPI enabled, you are ready to go. You can now call any code that uses
MPI in the IPython engines. And, all of this can be done interactively. Here we show a simple example that
uses mpi4py [mpi4py] version 1.1.0 or later.
First, lets define a simply function that uses MPI to calculate the sum of a distributed array. Save the
following text in a file called psum.py:
def psum(a):
locsum = np.sum(a)
rcvBuf = np.array(0.0,'d')
MPI.COMM_WORLD.Allreduce([locsum, MPI.DOUBLE],
[rcvBuf, MPI.DOUBLE],
op=MPI.SUM)
return rcvBuf
Note: It is assumed here that the mpi profile has been set up, as described here.
Finally, connect to the cluster and use this function interactively. In this case, we create a distributed array
and sum up all its elements in a distributed manner using our psum() function:
In [2]: c = Client(profile='mpi')
In [6]: view.scatter('a',np.arange(16,dtype='float'))
In [7]: view['a']
Out[7]: [array([ 0., 1., 2., 3.]),
array([ 4., 5., 6., 7.]),
array([ 8., 9., 10., 11.]),
array([ 12., 13., 14., 15.])]
In [8]: view['totalsum']
Out[8]: [120.0, 120.0, 120.0, 120.0]
Any Python code that makes calls to MPI can be used in this manner, including compiled C, C++ and Fortran
libraries that have been exposed to Python.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Enabling a DB Backend
The IPython Hub can store all task requests and results in a database. Currently supported backends are:
MongoDB, SQLite, and an in-memory DictDB.
This database behavior is optional due to its potential Cost, so you must enable one, either at the command-
line:
or in your ipcontroller_config.py:
c.HubFactory.db_class = "DictDB"
c.HubFactory.db_class = "MongoDB"
c.HubFactory.db_class = "SQLiteDB"
The most common use case for this is clients requesting results for tasks they did not submit, via:
In [1]: rc.get_result(task_id)
However, since we have this DB backend, we provide a direct query method in the Client for users who
want deeper introspection into their task history. The db_query() method of the Client is modeled after
MongoDB queries, so if you have used MongoDB it should look familiar. In fact, when the MongoDB
backend is in use, the query is relayed directly. When using other backends, the interface is emulated and
only a subset of queries is possible.
See also:
MongoDB query docs: http://www.mongodb.org/display/DOCS/Querying
Client.db_query() takes a dictionary query object, with keys from the TaskRecord key list, and val-
ues of either exact values to test, or MongoDB queries, which are dicts of The form: {'operator' :
'argument(s)'}. There is also an optional keys argument, that specifies which subset of keys should
be retrieved. The default is to retrieve all keys excluding the request and result buffers. db_query()
returns a list of TaskRecord dicts. Also like MongoDB, the msg_id key will always be included, whether
requested or not.
TaskRecord keys:
Key Type Description
msg_id uuid(ascii) The msg ID
header dict The request header
content dict The request content (likely empty)
buffers list(bytes) buffers containing serialized request objects
submitted datetime timestamp for time of submission (set by client)
client_uuid uuid(ascii) IDENT of client’s socket
engine_uuid uuid(ascii) IDENT of engine’s socket
started datetime time task began execution on engine
completed datetime time task finished execution (success or failure) on engine
resubmitted uuid(ascii) msg_id of resubmitted task (if applicable)
result_header dict header for result
result_content dict content for result
result_buffers list(bytes) buffers containing serialized request objects
queue str The name of the queue for the task (‘mux’ or ‘task’)
pyin str Python input source
pyout dict Python output (pyout message content)
pyerr dict Python traceback (pyerr message content)
stdout str Stream of stdout data
stderr str Stream of stderr data
MongoDB operators we emulate on all backends:
Example Queries
To get all msg_ids that are not completed, only retrieving their ID and start time:
All jobs started more than an hour ago, by clients other than me:
Cost
The advantage of the database backends is, of course, that large amounts of data can be stored that won’t
fit in memory. The basic DictDB ‘backend’ is actually to just store all of this information in a Python
dictionary. This is very fast, but will run out of memory quickly if you move a lot of data around, or your
cluster is to run for a long time.
Unfortunately, the DB backends (SQLite and MongoDB) right now are rather slow, and can still consume
large amounts of resources, particularly if large tasks or results are being created at a high frequency.
For this reason, we have added NoDB,a dummy backend that doesn’t actually store any information. When
you use this database, nothing is stored, and any request for results will result in a KeyError. This obviously
prevents later requests for results and task resubmission from functioning, but sometimes those nice features
are not as useful as keeping Hub memory under control.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This section is not thorough, and IPython.kernel.zmq needs a thorough security audit.
IPython’s IPython.kernel.zmq package exposes the full power of the Python interpreter over a TCP/IP
network for the purposes of parallel computing. This feature brings up the important question of IPython’s
security model. This document gives details about this model and how it is implemented in IPython’s
architecture.
To enable parallel computing, IPython has a number of different processes that run. These processes are
discussed at length in the IPython documentation and are summarized here:
• The IPython engine. This process is a full blown Python interpreter in which user code is executed.
Multiple engines are started to make parallel computing possible.
• The IPython hub. This process monitors a set of engines and schedulers, and keeps track of the state of
the processes. It listens for registration connections from engines and clients, and monitor connections
from schedulers.
• The IPython schedulers. This is a set of processes that relay commands and results between clients
and engines. They are typically on the same machine as the controller, and listen for connections from
engines and clients, but connect to the Hub.
• The IPython client. This process is typically an interactive Python process that is used to coordinate
the engines to get a parallel computation done.
Collectively, these processes are called the IPython cluster, and the hub and schedulers together are referred
to as the controller.
These processes communicate over any transport supported by ZeroMQ (tcp,pgm,infiniband,ipc) with a well
defined topology. The IPython hub and schedulers listen on sockets. Upon starting, an engine connects to
a hub and registers itself, which then informs the engine of the connection information for the schedulers,
and the engine then connects to the schedulers. These engine/hub and engine/scheduler connections persist
for the lifetime of each engine.
The IPython client also connects to the controller processes using a number of socket connections. As of
writing, this is one socket per scheduler (4), and 3 connections to the hub for a total of 7. These connections
persist for the lifetime of the client only.
A given IPython controller and set of engines engines typically has a relatively short lifetime. Typically this
lifetime corresponds to the duration of a single parallel simulation performed by a single user. Finally, the
hub, schedulers, engines, and client processes typically execute with the permissions of that same user. More
specifically, the controller and engines are not executed as root or with any other superuser permissions.
Application logic
When running the IPython kernel to perform a parallel computation, a user utilizes the IPython client to send
Python commands and data through the IPython schedulers to the IPython engines, where those commands
are executed and the data processed. The design of IPython ensures that the client is the only access point
for the capabilities of the engines. That is, the only way of addressing the engines is through a client.
A user can utilize the client to instruct the IPython engines to execute arbitrary Python commands. These
Python commands can include calls to the system shell, access the filesystem, etc., as required by the user’s
application code. From this perspective, when a user runs an IPython engine on a host, that engine has the
same capabilities and permissions as the user themselves (as if they were logged onto the engine’s host with
a terminal).
Overview
ZeroMQ provides exactly no security. For this reason, users of IPython must be very careful in managing
connections, because an open TCP/IP socket presents access to arbitrary execution as the user on the engine
machines. As a result, the default behavior of controller processes is to only listen for clients on the loopback
interface, and the client must establish SSH tunnels to connect to the controller processes.
Warning: If the controller’s loopback interface is untrusted, then IPython should be considered vulner-
able, and this extends to the loopback of all connected clients, which have opened a loopback port that
is redirected to the controller’s loopback port.
SSH
Since ZeroMQ provides no security, SSH tunnels are the primary source of secure connections. A connector
file, such as ipcontroller-client.json, will contain information for connecting to the controller,
possibly including the address of an ssh-server through with the client is to tunnel. The Client object then
creates tunnels using either [OpenSSH] or [Paramiko], depending on the platform. If users do not wish to
use OpenSSH or Paramiko, or the tunneling utilities are insufficient, then they may construct the tunnels
themselves, and simply connect clients and engines as if the controller were on loopback on the connecting
machine.
Authentication
To protect users of shared machines, [HMAC] digests are used to sign messages, using a shared key.
The Session object that handles the message protocol uses a unique key to verify valid messages. This can be
any value specified by the user, but the default behavior is a pseudo-random 128-bit number, as generated by
uuid.uuid4(). This key is used to initialize an HMAC object, which digests all messages, and includes
that digest as a signature and part of the message. Every message that is unpacked (on Controller, Engine,
and Client) will also be digested by the receiver, ensuring that the sender’s key is the same as the receiver’s.
No messages that do not contain this key are acted upon in any way. The key itself is never sent over the
network.
There is exactly one shared key per cluster - it must be the same everywhere. Typically, the controller creates
this key, and stores it in the private connection files ipython-{engine|client}.json. These files
are typically stored in the ~/.ipython/profile_<name>/security directory, and are maintained
as readable only by the owner, just as is common practice with a user’s keys in their .ssh directory.
Warning: It is important to note that the signatures protect against unauthorized messages, but, as there
is no encryption, provide exactly no protection of data privacy. It is possible, however, to use a cus-
tom serialization scheme (via Session.packer/unpacker traits) that does incorporate your own encryption
scheme.
There are a number of potential security vulnerabilities present in IPython’s architecture. In this section we
discuss those vulnerabilities and detail how the security architecture described above prevents them from
being exploited.
Unauthorized clients
The IPython client can instruct the IPython engines to execute arbitrary Python code with the permissions
of the user who started the engines. If an attacker were able to connect their own hostile IPython client to
the IPython controller, they could instruct the engines to execute code.
On the first level, this attack is prevented by requiring access to the controller’s ports, which are recom-
mended to only be open on loopback if the controller is on an untrusted local network. If the attacker does
have access to the Controller’s ports, then the attack is prevented by the capabilities based client authentica-
tion of the execution key. The relevant authentication information is encoded into the JSON file that clients
must present to gain access to the IPython controller. By limiting the distribution of those keys, a user can
grant access to only authorized persons, just as with SSH keys.
It is highly unlikely that an execution key could be guessed by an attacker in a brute force guessing attack.
A given instance of the IPython controller only runs for a relatively short amount of time (on the order of
hours). Thus an attacker would have only a limited amount of time to test a search space of size 2**128.
For added security, users can have arbitrarily long keys.
Warning: If the attacker has gained enough access to intercept loopback connections on either the
controller or client, then a duplicate message can be sent. To protect against this, recipients only allow
each signature once, and consider duplicates invalid. However, the duplicate message could be sent to
another recipient using the same key, and it would be considered valid.
Unauthorized engines
If an attacker were able to connect a hostile engine to a user’s controller, the user might unknowingly send
sensitive code or data to the hostile engine. This attacker’s engine would then have full access to that code
and data.
This type of attack is prevented in the same way as the unauthorized client attack, through the usage of the
capabilities based authentication scheme.
Unauthorized controllers
It is also possible that an attacker could try to convince a user’s IPython client or engine to connect to a
hostile IPython controller. That controller would then have full access to the code and data sent between the
IPython client and the IPython engines.
Again, this attack is prevented through the capabilities in a connection file, which ensure that a client or
engine connects to the correct controller. It is also important to note that the connection files also encode
the IP address and port that the controller is listening on, so there is little chance of mistakenly connecting
to a controller running on a different IP address and port.
When starting an engine or client, a user must specify the key to use for that connection. Thus, in order to
introduce a hostile controller, the attacker must convince the user to use the key associated with the hostile
controller. As long as a user is diligent in only using keys from trusted sources, this attack is not possible.
Note: I may be wrong, the unauthorized controller may be easier to fake than this.
A number of other measures are taken to further limit the security risks involved in running the IPython
kernel.
First, by default, the IPython controller listens on random port numbers. While this can be overridden by
the user, in the default configuration, an attacker would have to do a port scan to even find a controller to
attack. When coupled with the relatively short running time of a typical controller (on the order of hours),
an attacker would have to work extremely hard and extremely fast to even find a running controller to attack.
Second, much of the time, especially when run on supercomputers or clusters, the controller is running
behind a firewall. Thus, for engines or client to connect to the controller:
• The different processes have to all be behind the firewall.
or:
• The user has to use SSH port forwarding to tunnel the connections through the firewall.
In either case, an attacker is presented with additional barriers that prevent attacking or even probing the
system.
Summary
IPython’s architecture has been carefully designed with security in mind. The capabilities based authentica-
tion model, in conjunction with SSH tunneled TCP/IP channels, address the core potential vulnerabilities in
the system, while still enabling user’s to use the system in open networks.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Introduction
The Python programming language is an increasingly popular language for numerical computing. This
is due to a unique combination of factors. First, Python is a high-level and interactive language that is
well matched to interactive numerical work. Second, it is easy (often times trivial) to integrate legacy
C/C++/Fortran code into Python. Third, a large number of high-quality open source projects provide all the
needed building blocks for numerical computing: numerical arrays (NumPy), algorithms (SciPy), 2D/3D
Visualization (matplotlib, Mayavi, Chaco), Symbolic Mathematics (Sage, Sympy) and others.
The IPython project is a core part of this open-source toolchain and is focused on creating a comprehensive
environment for interactive and exploratory computing in the Python programming language. It enables all
of the above tools to be used interactively and consists of two main components:
• An enhanced interactive Python shell with support for interactive plotting and visualization.
• An architecture for interactive parallel computing.
With these components, it is possible to perform all aspects of a parallel computation interactively. This
type of workflow is particularly relevant in scientific and numerical computing where algorithms, code and
data are continually evolving as the user/developer explores a problem. The broad threads in computing
(commodity clusters, multicore, cloud computing, etc.) make these capabilities of IPython particularly
relevant.
While IPython is a cross platform tool, it has particularly strong support for Windows based compute clusters
running Windows HPC Server 2008. This document describes how to get started with IPython on Windows
HPC Server 2008. The content and emphasis here is practical: installing IPython, configuring IPython to
use the Windows job scheduler and running example parallel programs interactively. A more complete
description of IPython’s parallel computing capabilities can be found in IPython’s online documentation
(http://ipython.org/documentation.html).
This document assumes that you already have a cluster running Windows HPC Server 2008. Here is a broad
overview of what is involved with setting up such a cluster:
1. Install Windows Server 2008 on the head and compute nodes in the cluster.
2. Setup the network configuration on each host. Each host should have a static IP address.
3. On the head node, activate the “Active Directory Domain Services” role and make the head node the
domain controller.
4. Join the compute nodes to the newly created Active Directory (AD) domain.
5. Setup user accounts in the domain with shared home directories.
6. Install the HPC Pack 2008 on the head node to create a cluster.
7. Install the HPC Pack 2008 on the compute nodes.
More details about installing and configuring Windows HPC Server 2008 can be found on the Windows HPC
Home Page (http://www.microsoft.com/hpc). Regardless of what steps you follow to set up your cluster, the
remainder of this document will assume that:
• There are domain users that can log on to the AD domain and submit jobs to the cluster scheduler.
• These domain users have shared home directories. While shared home directories are not required to
use IPython, they make it much easier to use IPython.
IPython and all of its dependencies are freely available and open source. These packages provide a powerful
and cost-effective approach to numerical and scientific computing on Windows. The following dependencies
are needed to run IPython on Windows:
• Python 2.6 or 2.7 (http://www.python.org)
• pywin32 (http://sourceforge.net/projects/pywin32/)
• PyReadline (https://launchpad.net/pyreadline)
• pyzmq (http://github.com/zeromq/pyzmq/downloads)
• IPython (http://ipython.org)
In addition, the following dependencies are needed to run the demos described in this document.
• NumPy and SciPy (http://www.scipy.org)
• matplotlib (http://matplotlib.org)
The easiest way of obtaining these dependencies is through the Enthought Python Distribution (EPD) (http:
//www.enthought.com/products/epd.php). EPD is produced by Enthought, Inc. and contains all of these
packages and others in a single installer and is available free for academic users. While it is also possible
to download and install each package individually, this is a tedious process. Thus, we highly recommend
using EPD to install these packages on Windows.
Regardless of how you install the dependencies, here are the steps you will need to follow:
1. Install all of the packages listed above, either individually or using EPD on the head node, compute
nodes and user workstations.
2. Make sure that C:\Python27 and C:\Python27\Scripts are in the system %PATH% variable
on each node.
3. Install the latest development version of IPython. This can be done by downloading the the develop-
ment version from the IPython website (http://ipython.org) and following the installation instructions.
Further details about installing IPython or its dependencies can be found in the online IPython documenta-
tion (http://ipython.org/documentation.html) Once you are finished with the installation, you can try IPython
out by opening a Windows Command Prompt and typing ipython. This will start IPython’s interactive
shell and you should see something like the following:
Z:\>ipython
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.
In [1]:
To use IPython’s parallel computing capabilities, you will need to start an IPython cluster. An IPython
cluster consists of one controller and multiple engines:
IPython controller The IPython controller manages the engines and acts as a gateway between the engines
and the client, which runs in the user’s interactive IPython session. The controller is started using the
ipcontroller command.
IPython engine IPython engines run a user’s Python code in parallel on the compute nodes. Engines are
starting using the ipengine command.
Once these processes are started, a user can run Python code interactively and in parallel on the engines
from within the IPython shell using an appropriate client. This includes the ability to interact with, plot and
visualize data from the engines.
IPython has a command line program called ipcluster that automates all aspects of starting the controller
and engines on the compute nodes. ipcluster has full support for the Windows HPC job scheduler,
meaning that ipcluster can use this job scheduler to start the controller and engines. In our experience,
the Windows HPC job scheduler is particularly well suited for interactive applications, such as IPython.
Once ipcluster is configured properly, a user can start an IPython cluster from their local workstation
almost instantly, without having to log on to the head node (as is typically required by Unix based job
schedulers). This enables a user to move seamlessly between serial and parallel computations.
In this section we show how to use ipcluster to start an IPython cluster using the Windows HPC Server
2008 job scheduler. To make sure that ipcluster is installed and working properly, you should first try
to start an IPython cluster on your local host. To do this, open a Windows Command Prompt and type the
following command:
ipcluster start -n 2
You should see a number of messages printed to the screen. The result should look something like this:
At this point, the controller and two engines are running on your local host. This configuration is useful for
testing and for situations where you want to take advantage of multiple cores on your local computer.
Now that we have confirmed that ipcluster is working properly, we describe how to configure and run
an IPython cluster on an actual compute cluster running Windows HPC Server 2008. Here is an outline of
the needed steps:
1. Create a cluster profile using: ipython profile create mycluster --parallel
2. Edit configuration files in the directory .ipython\cluster_mycluster
3. Start the cluster using: ipcluster start --profile=mycluster -n 32
In most cases, you will have to create a cluster profile to use IPython on a cluster. A cluster profile is a
name (like “mycluster”) that is associated with a particular cluster configuration. The profile name is used
by ipcluster when working with the cluster.
Associated with each cluster profile is a cluster directory. This cluster directory is a specially named direc-
tory (typically located in the .ipython subdirectory of your home directory) that contains the configura-
tion files for a particular cluster profile, as well as log files and security keys. The naming convention for
cluster directories is: profile_<profile name>. Thus, the cluster directory for a profile named “foo”
would be .ipython\cluster_foo.
To create a new cluster profile (named “mycluster”) and the associated cluster directory, type the following
command at the Windows Command Prompt:
The output of this command is shown in the screenshot below. Notice how ipcluster prints out the
location of the newly created profile directory:
Z:\>
Next, you will need to configure the newly created cluster profile by editing the following configuration files
in the cluster directory:
• ipcluster_config.py
• ipcontroller_config.py
• ipengine_config.py
When ipcluster is run, these configuration files are used to determine how the engines and controller
will be started. In most cases, you will only have to set a few of the attributes in these files.
To configure ipcluster to use the Windows HPC job scheduler, you will need to edit the following
attributes in the file ipcluster_config.py:
# Set these at the top of the file to tell ipcluster to use the
# Windows HPC job scheduler.
c.IPClusterStart.controller_launcher_class = 'WindowsHPCControllerLauncher'
c.IPClusterEngines.engine_launcher_class = 'WindowsHPCEngineSetLauncher'
# Set these to the host name of the scheduler (head node) of your cluster.
c.WindowsHPCControllerLauncher.scheduler = 'HEADNODE'
c.WindowsHPCEngineSetLauncher.scheduler = 'HEADNODE'
There are a number of other configuration attributes that can be set, but in most cases these will be sufficient
to get you started.
Warning: If any of your configuration attributes involve specifying the location of shared directories or
files, you must make sure that you use UNC paths like \\host\share. It is helpful to specify these
paths using raw Python strings: r'\\host\share' to make sure that the backslashes are properly
escaped.
Once a cluster profile has been configured, starting an IPython cluster using the profile is simple:
The -n option tells ipcluster how many engines to start (in this case 32). Stopping the cluster is as
simple as typing Control-C.
føø When ipcluster start is run the first time, ipcluster creates two XML job description files
in the cluster directory:
• ipcontroller_job.xml
• ipengineset_job.xml
Once these files have been created, they can be imported into the HPC Job Manager application. Then, the
controller and engines for that profile can be started using the HPC Job Manager directly, without using
ipcluster. However, anytime the cluster profile is re-configured, ipcluster start must be run
again to regenerate the XML job description files. The following screenshot shows what the HPC Job
Manager interface looks like with a running IPython cluster.
Once you have started your IPython cluster, you can start to use it. To do this, open up a new Windows
Command Prompt and start up IPython’s interactive shell by typing:
ipython
Then you can create a DirectView instance for your profile and use the resulting instance to do a simple
interactive parallel computation. In the code and screenshot that follows, we take a simple Python function
and apply it to each element of an array of integers in parallel using the DirectView.map() method:
In [2]: c = Client(profile='mycluster')
In [4]: c.ids
Out[4]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14]
[0,
1,
1024,
59049,
1048576,
9765625,
60466176,
282475249,
1073741824,
3486784401L,
10000000000L,
25937424601L,
61917364224L,
137858491849L,
289254654976L]
The map() method has the same signature as Python’s builtin map() function, but runs the calculation in
parallel. More involved examples of using DirectView are provided in the examples that follow.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Parallel examples
In this section we describe two more involved examples of using an IPython cluster to perform a parallel
computation. We will be doing some plotting, so we start IPython with matplotlib integration by typing:
ipython --matplotlib
at the system command line. Or you can enable matplotlib integration at any point with:
In [1]: %matplotlib
In this example we would like to study the distribution of digits in the number pi (in base 10). While it
is not known if pi is a normal number (a number is normal in base 10 if 0-9 occur with equal likelihood)
numerical investigations suggest that it is. We will begin with a serial calculation on 10,000 digits of pi and
then perform a parallel calculation involving 150 million digits.
In both the serial and parallel calculation we will be using functions defined in the pidigits.py file,
which is available in the examples/parallel directory of the IPython source distribution. These func-
tions provide basic facilities for working with the digits of pi and can be loaded into IPython by putting
pidigits.py in your current working directory and then doing:
Serial calculation
For the serial calculation, we will use SymPy to calculate 10,000 digits of pi and then look at the frequencies
of the digits 0-9. Out of 10,000 digits, we expect each digit to occur 1,000 times. While SymPy is capable
of calculating many more digits of pi, our purpose here is to set the stage for the much larger parallel
calculation.
In this example, we use two functions from pidigits.py: one_digit_freqs() (which calculates
how many times each digit occurs) and plot_one_digit_freqs() (which uses Matplotlib to plot the
result). Here is an interactive IPython session that uses these functions with SymPy:
In [8]: pi = sympy.pi.evalf(40)
In [9]: pi
Out[9]: 3.141592653589793238462643383279502884197
In [10]: pi = sympy.pi.evalf(10000)
In [14]: plot_one_digit_freqs(freqs)
Out[14]: [<matplotlib.lines.Line2D object at 0x18a55290>]
The resulting plot of the single digit counts shows that each digit occurs approximately 1,000 times, but that
with only 10,000 digits the statistical fluctuations are still rather large:
It is clear that to reduce the relative fluctuations in the counts, we need to look at many more digits of pi.
That brings us to the parallel calculation.
Parallel calculation
Calculating many digits of pi is a challenging computational problem in itself. Because we want to focus on
the distribution of digits in this example, we will use pre-computed digit of pi from the website of Professor
Yasumasa Kanada at the University of Tokyo (http://www.super-computing.org). These digits come in a set
of text files (ftp://pi.super-computing.org/.2/pi200m/) that each have 10 million digits of pi.
For the parallel calculation, we have copied these files to the local hard drives of the compute nodes. A total
of 15 of these files will be used, for a total of 150 million digits of pi. To make things a little more interesting
we will calculate the frequencies of all 2 digits sequences (00-99) and then plot the result using a 2D matrix
in Matplotlib.
The overall idea of the calculation is simple: each IPython engine will compute the two digit counts for the
digits in a single file. Then in a final step the counts from each engine will be added up. To perform this
calculation, we will need two top-level functions from pidigits.py:
"""
d = txt_file_to_digits(filename)
freqs = one_digit_freqs(d)
return freqs
def compute_two_digit_freqs(filename):
"""
Read digits of pi from a file and compute the 2 digit frequencies.
"""
d = txt_file_to_digits(filename)
freqs = two_digit_freqs(d)
return freqs
def reduce_freqs(freqlist):
"""
Add up a list of freq counts to get the total counts.
We will also use the plot_two_digit_freqs() function to plot the results. The code to run this
calculation in parallel is contained in examples/parallel/parallelpi.py. This code can be run
in parallel using IPython by following these steps:
1. Use ipcluster to start 15 engines. We used 16 cores of an SGE linux cluster (1 controller + 15
engines).
2. With the file parallelpi.py in your current working directory, open up IPython, enable mat-
plotlib, and type run parallelpi.py. This will download the pi files via ftp the first time you
run it, if they are not present in the Engines’ working directory.
When run on our 16 cores, we observe a speedup of 14.2x. This is slightly less than linear scaling (16x)
because the controller is also running on one of the cores.
To emphasize the interactive nature of IPython, we now show how the calculation can also be run by simply
typing the commands from parallelpi.py interactively into IPython:
In [3]: c.ids
Out[3]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14]
In [7]: files
Out[7]:
['pi200m.ascii.01of20',
'pi200m.ascii.02of20',
'pi200m.ascii.03of20',
'pi200m.ascii.04of20',
'pi200m.ascii.05of20',
'pi200m.ascii.06of20',
'pi200m.ascii.07of20',
'pi200m.ascii.08of20',
'pi200m.ascii.09of20',
'pi200m.ascii.10of20',
'pi200m.ascii.11of20',
'pi200m.ascii.12of20',
'pi200m.ascii.13of20',
'pi200m.ascii.14of20',
'pi200m.ascii.15of20']
In [11]: plot_two_digit_freqs(freqs)
Out[11]: <matplotlib.image.AxesImage object at 0x18beb110>
The resulting plot generated by Matplotlib is shown below. The colors indicate which two digit sequences
are more (red) or less (blue) likely to occur in the first 150 million digits of pi. We clearly see that the
sequence “41” is most likely and that “06” and “07” are least likely. Further analysis would show that the
relative size of the statistical fluctuations have decreased compared to the 10,000 digit calculation.
Conclusion
To conclude these examples, we summarize the key features of IPython’s parallel architecture that have been
demonstrated:
• Serial code can be parallelized often with only a few extra lines of code. We have used the
DirectView and LoadBalancedView classes for this purpose.
• The resulting parallel code can be run without ever leaving the IPython’s interactive shell.
• Any data computed in parallel can be explored interactively through visualization or further numerical
calculations.
• We have run these examples on a cluster running RHEL 5 and Sun GridEngine. IPython’s built
in support for SGE (and other batch systems) makes it easy to get started with IPython’s parallel
capabilities.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
DAG Dependencies
Often, parallel workflow is described in terms of a Directed Acyclic Graph or DAG. A popular library
for working with Graphs is NetworkX. Here, we will walk through a demo mapping a nx DAG to task
dependencies.
The full script that runs this demo can be found in examples/parallel/dagdeps.py.
The ‘G’ in DAG is ‘Graph’. A Graph is a collection of nodes and edges that connect the nodes. For our
purposes, each node would be a task, and each edge would be a dependency. The ‘D’ in DAG stands for
‘Directed’. This means that each edge has a direction associated with it. So we can interpret the edge (a,b)
as meaning that b depends on a, whereas the edge (b,a) would mean a depends on b. The ‘A’ is ‘Acyclic’,
meaning that there must not be any closed loops in the graph. This is important for dependencies, because if
a loop were closed, then a task could ultimately depend on itself, and never be able to run. If your workflow
can be described as a DAG, then it is impossible for your dependencies to cause a deadlock.
A Sample DAG
3 4
2 1
import networkx as nx
G = nx.DiGraph()
For demonstration purposes, we have a function that generates a random DAG with a given number of nodes
and edges.
In [2]: G = random_dag(32,128)
Now, we need to build our dict of jobs corresponding to the nodes on the graph:
In [3]: jobs = {}
Once we have a dict of jobs matching the nodes on the graph, we can start submitting jobs, and linking up
the dependencies. Since we don’t know a job’s msg_id until it is submitted, which is necessary for building
dependencies, it is critical that we don’t submit any jobs before other jobs it may depend on. Fortunately,
NetworkX provides a topological_sort() method which ensures exactly this. It presents an iterable,
that guarantees that when you arrive at a node, you have already visited all the nodes it on which it depends:
In [5]: rc = Client()
In [5]: view = rc.load_balanced_view()
In [6]: results = {}
Now that we have submitted all the jobs, we can wait for the results:
In [8]: view.wait(results.values())
Now, at least we know that all the jobs ran and did not fail (r.get() would have raised an error if a task
failed). But we don’t know that the ordering was properly respected. For this, we can use the metadata
attribute of each AsyncResult.
These objects store a variety of metadata about each task, including various timestamps. We can validate
that the dependencies were respected by checking that each task was started after all of its predecessors were
completed:
We can also validate the graph visually. By drawing the graph with each node’s x-position as its start time,
all arrows must be pointing to the right if dependencies were respected. For spreading, the y-position will
be the runtime of the task, so long tasks will be at the top, and quick, small tasks will be at the bottom.
29
13 11 21
19 17
10 2 30 16 5 18
1
15
14 20 12
23 9
31
24 4 26 25 3 8
27
6
28
7 0
22
Fig. 6.1: Time started on x, runtime on y, and color-coded by engine-id (in this case there were four engines).
Edges denote dependencies.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: There are still many sections to fill out in this doc
Caveats
First, some caveats about the detailed workings of parallel computing with 0MQ and IPython.
When numpy arrays are passed as arguments to apply or via data-movement methods, they are not copied.
This means that you must be careful if you are sending an array that you intend to work on. PyZMQ does
allow you to track when a message has been sent so you can know when it is safe to edit the buffer, but
IPython only allows for this.
It is also important to note that the non-copying receive of a message is read-only. That means that if you
intend to work in-place on an array that you have sent or received, you must copy it. This is true for both
numpy arrays sent to engines and numpy arrays retrieved as results.
The following will fail:
In [3]: A = numpy.zeros(2)
In [5]: rc[0].apply_sync(setter, A)
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
˓→<string> in <module>()
<ipython-input-12-c3e7afeb3075> in setter(a)
RuntimeError: array is not writeable
If you do need to edit the array in-place, just remember to copy the array if it’s read-only. The ndarray.
flags.writeable flag will tell you if you can write to an array.
In [3]: A = numpy.zeros(2)
In [5]: rc[0].apply_sync(setter, A)
Out[5]: array([ 1., 0.])
If you want to safely edit an array in-place after sending it, you must use the track=True flag. IPython
always performs non-copying sends of arrays, which return immediately. You must instruct IPython track
those messages at send time in order to know for sure that the send has completed. AsyncResults have a
sent property, and wait_on_send() method for checking and waiting for 0MQ to finish with a buffer.
In [5]: A = numpy.random.random((1024,1024))
In [6]: view.track=True
In [8]: ar.sent
Out[8]: False
What is sendable?
If IPython doesn’t know what to do with an object, it will pickle it. There is a short list of objects that are
not pickled: buffers, str/bytes objects, and numpy arrays. These are handled specially by IPython
in order to prevent the copying of data. Sending bytes or numpy arrays will result in exactly zero in-memory
copies of your data (unless the data is very small).
If you have an object that provides a Python buffer interface, then you can always send that buffer without
copying - and reconstruct the object on the other side in your own code. It is possible that the object
reconstruction will become extensible, so you can add your own non-copying types, but this does not yet
exist.
Closures
Just about anything in Python is pickleable. The one notable exception is objects (generally functions) with
closures. Closures can be a complicated topic, but the basic principal is that functions that refer to variables
in their parent scope have closures.
An example of a function that uses a closure:
def f(a):
def inner():
# inner will have a closure
return a
return inner
f1 = f(1)
f2 = f(2)
f1() # returns 1
f2() # returns 2
f1 and f2 will have closures referring to the scope in which inner was defined, because they use the
variable ‘a’. As a result, you would not be able to send f1 or f2 with IPython. Note that you would be
able to send f. This is only true for interactively defined functions (as are often used in decorators), and
only when there are variables used inside the inner function, that are defined in the outer function. If the
names are not in the outer function, then there will not be a closure, and the generated function will look in
globals() for the name:
def g(b):
# note that `b` is not referenced in inner's scope
def inner():
# this inner will *not* have a closure
return a
return inner
g1 = g(1)
g2 = g(2)
g1() # raises NameError on 'a'
a=5
g2() # returns 5
g1 and g2 will be sendable with IPython, and will treat the engine’s namespace as globals(). The pull()
method is implemented based on this principle. If we did not provide pull, you could implement it yourself
with apply, by simply returning objects out of the global namespace:
In [10]: view.apply(lambda : a)
# is equivalent to
In [11]: view.pull('a')
Running Code
There are two principal units of execution in Python: strings of Python code (e.g. ‘a=5’), and Python
functions. IPython is designed around the use of functions via the core Client method, called apply.
Apply
The principal method of remote execution is apply(), of View objects. The Client provides the full ex-
ecution and communication API for engines via its low-level send_apply_message() method, which
is used by all higher level methods of its Views.
f [function] The function to be called remotely
args [tuple/list] The positional arguments passed to f
kwargs [dict] The keyword arguments passed to f
flags for all views:
block [bool (default: view.block)] Whether to wait for the result, or return immediately.
False: returns AsyncResult
True: returns actual result(s) of f(*args, **kwargs)
if multiple targets: list of results, matching targets
track [bool [default view.track]] whether to track non-copying sends.
targets [int,list of ints, ‘all’, None [default view.targets]] Specify the destination of the job.
if ‘all’ or None: Run on all active engines
if list: Run on each specified engine
if int: Run on single engine
Note that LoadBalancedView uses targets to restrict possible destinations. LoadBalanced calls will
always execute in just one location.
flags only in LoadBalancedViews:
after [Dependency or collection of msg_ids] Only for load-balanced execution (targets=None) Specify a
list of msg_ids as a time-based dependency. This job will only be run after the dependencies have
been met.
follow [Dependency or collection of msg_ids] Only for load-balanced execution (targets=None) Specify a
list of msg_ids as a location-based dependency. This job will only be run on an engine where this
dependency is met.
timeout [float/int or None] Only for load-balanced execution (targets=None) Specify an amount of time (in
seconds) for the scheduler to wait for dependencies to be met before failing with a DependencyTime-
out.
For executing strings of Python code, DirectView ‘s also provide an execute() and a run() method,
which rather than take functions and arguments, take simple strings. execute simply takes a string of
Python code to execute, and sends it to the Engine(s). run is the same as execute, but for a file, rather
than a string. It is simply a wrapper that does something very similar to execute(open(f).read()).
Views
The principal extension of the Client is the View class. The client is typically a singleton for connecting
to a cluster, and presents a low-level interface to the Hub and Engines. Most real usage will involve creating
one or more View objects for working with engines in various ways.
DirectView
Creating a DirectView
DirectViews can be created in two ways, by index access to a client, or by a client’s view() method.
Index access to a Client works in a few ways. First, you can create DirectViews to single engines simply by
accessing the client by engine id:
In [2]: rc[0]
Out[2]: <DirectView 0>
Other methods for accessing elements, such as slicing and negative indexing, work by passing the index
directly to the client’s ids list, so:
# negative index
In [2]: rc[-1]
Out[2]: <DirectView 3>
# or slicing:
In [3]: rc[::2]
Out[3]: <DirectView [0,2]>
In [3]: rc[rc.ids[::2]]
Out[3]: <DirectView [0,2]>
Also note that the slice is evaluated at the time of construction of the DirectView, so the targets will not
change over time if engines are added/removed from the cluster.
The DirectView is the simplest way to work with one or more engines directly (hence the name).
For instance, to get the process ID of all your engines:
In [5]: import os
In [6]: dview.apply_sync(os.getpid)
Out[6]: [1354, 1356, 1358, 1360]
In [6]: dview.apply_sync(socket.gethostname)
Out[6]: ['tesla', 'tesla', 'edison', 'edison', 'edison']
Since a Python namespace is just a dict, DirectView objects provide dictionary-style access by key
and methods such as get() and update() for convenience. This make the remote namespaces of the
engines appear as a local dictionary. Underneath, these methods call apply():
In [51]: dview['a']=['foo','bar']
In [52]: dview['a']
Out[52]: [ ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'] ]
Sometimes it is useful to partition a sequence and push the partitions to different engines. In MPI lan-
guage, this is know as scatter/gather and we follow that terminology. However, it is important to remember
that in IPython’s Client class, scatter() is from the interactive IPython session to the engines and
gather() is from the engines back to the interactive IPython session. For scatter/gather operations be-
tween engines, MPI should be used:
In [58]: dview.scatter('a',range(16))
Out[58]: [None,None,None,None]
In [59]: dview['a']
Out[59]: [ [0, 1, 2, 3], [4, 5, 6, 7], [8, 9, 10, 11], [12, 13, 14, 15] ]
In [60]: dview.gather('a')
Out[60]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
push()
pull()
LoadBalancedView
The LoadBalancedView is the class for load-balanced execution via the task scheduler. These views
always run tasks on exactly one engine, but let the scheduler determine where that should be, allowing load-
balancing of tasks. The LoadBalancedView does allow you to specify restrictions on where and when tasks
can execute, for more complicated load-balanced workflows.
Data Movement
Since the LoadBalancedView does not know where execution will take place, explicit data movement
methods like push/pull and scatter/gather do not make sense, and are not provided.
Results
AsyncResults
Our primary representation of the results of remote execution is the AsyncResult object, based on the ob-
ject of the same name in the built-in multiprocessing.pool module. Our version provides a superset
of that interface.
The basic principle of the AsyncResult is the encapsulation of one or more results not yet completed.
Execution methods (including data movement, such as push/pull) will all return AsyncResults when
block=False.
The basic interface of the AsyncResult is exactly that of the AsyncResult in multiprocessing.pool,
and consists of four methods:
class AsyncResult
The stdlib AsyncResult spec
wait([timeout ])
Wait until the result is available or until timeout seconds pass. This method always returns
None.
ready()
Return whether the call has completed.
successful()
Return whether the call completed without raising an exception. Will raise AssertionError
if the result is not ready.
get([timeout ])
Return the result when it arrives. If timeout is not None and the result does not arrive within
timeout seconds then TimeoutError is raised. If the remote call raised an exception then that
exception will be reraised as a RemoteError by get().
While an AsyncResult is not done, you can check on it with its ready() method, which will return whether
the AR is done. You can also wait on an AsyncResult with its wait() method. This method blocks until
the result arrives. If you don’t want to wait forever, you can pass a timeout (in seconds) as an argument to
wait(). wait() will always return None, and should never raise an error.
ready() and wait() are insensitive to the success or failure of the call. After a result is done,
successful() will tell you whether the call completed without raising an exception.
If you actually want the result of the call, you can use get(). Initially, get() behaves just like wait(),
in that it will block until the result is ready, or until a timeout is met. However, unlike wait(), get() will
raise a TimeoutError if the timeout is reached and the result is still not ready. If the result arrives before
the timeout is reached, then get() will return the result itself if no exception was raised, and will raise an
exception if there was.
Here is where we start to expand on the multiprocessing interface. Rather than raising the original exception,
a RemoteError will be raised, encapsulating the remote exception with some metadata. If the AsyncResult
represents multiple calls (e.g. any time targets is plural), then a CompositeError, a subclass of Remo-
teError, will be raised.
See also:
For more information on remote exceptions, see the section in the Direct Interface.
Extended interface
Other extensions of the AsyncResult interface include convenience wrappers for get(). AsyncResults
have a property, result, with the short alias r, which simply call get(). Since our object is designed
for representing parallel results, it is expected that many calls (any of those submitted via DirectView) will
map results to engine IDs. We provide a get_dict(), which is also a wrapper on get(), which returns
a dictionary of the individual results, keyed by engine ID.
You can also prevent a submitted job from actually executing, via the AsyncResult’s abort() method.
This will instruct engines to not execute the job when it arrives.
The larger extension of the AsyncResult API is the metadata attribute. The metadata is a dictionary (with
attribute access) that contains, logically enough, metadata about the execution.
Metadata keys:
timestamps
submitted When the task left the Client
started When the task started execution on the engine
completed When execution finished on the engine
received When the result arrived on the Client
note that it is not known when the result arrived in 0MQ on the client, only when it arrived in Python
via Client.spin(), so in interactive use, this may not be strictly informative.
Information about the engine
engine_id The integer id
The Hub sees all traffic that may pass through the schedulers between engines and clients. It does this so
that it can track state, allowing multiple clients to retrieve results of computations submitted by their peers,
as well as persisting the state to a database.
queue_status
You can check the status of the queues of the engines with this command.
result_status
check on results
purge_results
forget results (conserve resources)
There are a few actions you can do with Engines that do not involve execution. These messages are sent via
the Control socket, and bypass any long queues of waiting execution jobs
abort
Sometimes you may want to prevent a job you have submitted from actually running. The
method for this is abort(). It takes a container of msg_ids, and instructs the Engines to not
run the jobs if they arrive. The jobs will then fail with an AbortedTask error.
clear
You may want to purge the Engine(s) namespace of any data you have left in it. After running
clear, there will be no names in the Engine’s namespace
shutdown
You can also instruct engines (and the Controller) to terminate from a Client. This can be useful
when a job is finished, since you can shutdown all the processes with a single command.
Synchronization
Since the Client is a synchronous object, events do not automatically trigger in your interactive session
- you must poll the 0MQ sockets for incoming messages. Note that this polling does not actually make
any network requests. It simply performs a select operation, to check if messages are already in local
memory, waiting to be handled.
The method that handles incoming messages is spin(). This method flushes any waiting messages on the
various incoming sockets, and updates the state of the Client.
If you need to wait for particular results to finish, you can use the wait() method, which will call spin()
until the messages are no longer outstanding. Anything that represents a collection of messages, such as a
list of msg_ids or one or more AsyncResult objects, can be passed as argument to wait. A timeout can be
specified, which will prevent the call from blocking for more than a specified time, but the default behavior
is to wait forever.
The client also has an outstanding attribute - a set of msg_ids that are awaiting replies. This is the
default if wait is called with no arguments - i.e. wait on all outstanding messages.
Map
Many parallel computing problems can be expressed as a map, or running a single program with a variety
of different inputs. Python has a built-in map(), which does exactly this, and many parallel execution tools
in Python, such as the built-in multiprocessing.Pool object provide implementations of map. All
View objects provide a map() method as well, but the load-balanced and direct implementations differ.
Views’ map methods can be called on any number of sequences, but they can also take the block and
bound keyword arguments, just like apply(), but only as keywords.
dview.map(*sequences, block=None)
@parallel()
@remote()
RemoteFunction
ParallelFunction
Dependencies
@depend()
@require()
Dependency
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
We have rewritten our parallel computing tools to use 0MQ and Tornado. The redesign has resulted in dra-
matically improved performance, as well as (we think), an improved interface for executing code remotely.
This doc is to help users of IPython.kernel transition their codes to the new code.
Processes
The process model for the new parallel code is very similar to that of IPython.kernel. There is still a
Controller, Engines, and Clients. However, the the Controller is now split into multiple processes, and can
even be split across multiple machines. There does remain a single ipcontroller script for starting all of the
controller processes.
See also:
Detailed Parallel Process doc for configuring and launching IPython processes.
Creating a Client
Creating a client with default settings has not changed much, though the extended options have. One sig-
nificant change is that there are no longer multiple Client classes to represent the various execution models.
There is just one low-level Client object for connecting to the cluster, and View objects are created from that
Client that provide the different interfaces for execution.
To create a new client, and set up the default direct and load-balanced objects:
# old
In [1]: from IPython.kernel import client as kclient
In [3]: tc = kclient.TaskClient()
# new
In [1]: from IPython.parallel import Client
In [2]: rc = Client()
Apply
The main change to the API is the addition of the apply() to the View objects. This is a method that takes
view.apply(f,*args,**kwargs), and calls f(*args, **kwargs) remotely on one or more
engines, returning the result. This means that the natural unit of remote execution is no longer a string of
Python code, but rather a Python function.
• non-copying sends (track)
• remote References
The flags for execution have also changed. Previously, there was only block denoting whether to wait for
results. This remains, but due to the addition of fully non-copying sends of arrays and buffers, there is also
a track flag, which instructs PyZMQ to produce a MessageTracker that will let you know when it is
safe again to edit arrays in-place.
The result of a non-blocking call to apply is now an AsyncResult object.
MultiEngine to DirectView
The multiplexing interface previously provided by the MultiEngineClient is now provided by the Di-
rectView. Once you have a Client connected, you can create a DirectView with index-access to the client
(view = client[1:5]). The core methods for communicating with engines remain: execute, run,
push, pull, scatter, gather. These methods all behave in much the same way as they did on a
MultiEngineClient.
# old
In [2]: mec.execute('a=5', targets=[0,1,2])
# new
In [2]: view.execute('a=5', targets=[0,1,2])
# or
In [2]: rc[0,1,2].execute('a=5')
dview.apply(lambda : globals().keys())
Task to LoadBalancedView
Load-Balancing has changed more than Multiplexing. This is because there is no longer a notion of a
StringTask or a MapTask, there are simply Python functions to call. Tasks are now simpler, because they are
no longer composites of push/execute/pull/clear calls, they are a single function that takes arguments, and
returns objects.
The load-balanced interface is provided by the LoadBalancedView class, created by the client:
A simple task would consist of sending some data, calling a function on that data, plus some data that
was resident on the engine already, and then pulling back some results. This can all be done with a single
function.
Let’s say you want to compute the dot product of two matrices, one of which resides on the engine, and
another resides on the client. You might construct a task that looks like this:
In [10]: st = kclient.StringTask("""
import numpy
C=numpy.dot(A,B)
""",
push=dict(B=B),
pull='C'
)
In [12]: tr = tc.get_task_result(tid)
In [13]: C = tc['C']
In [13]: C = ar.get()
Note the use of Reference This is a convenient representation of an object that exists in the engine’s
namespace, so you can pass remote objects as arguments to your task functions.
Also note that in the kernel model, after the task is run, ‘A’, ‘B’, and ‘C’ are all defined on the engine. In order
to deal with this, there is also a clear_after flag for Tasks to prevent pollution of the namespace, and
bloating of engine memory. This is not necessary with the new code, because only those objects explicitly
pushed (or set via globals()) will be resident on the engine beyond the duration of the task.
See also:
Dependencies also work very differently than in IPython.kernel. See our doc on Dependencies for details.
See also:
Our Task Interface doc for a simple tutorial with the LoadBalancedView.
PendingResults to AsyncResults
With the departure from Twisted, we no longer have the Deferred class for representing unfinished
results. For this, we have an AsyncResult object, based on the object of the same name in the built-in
multiprocessing.pool module. Our version provides a superset of that interface.
However, unlike in IPython.kernel, we do not have PendingDeferred, PendingResult, or TaskResult objects.
Simply this one object, the AsyncResult. Every asynchronous (block=False) call returns one.
The basic methods of an AsyncResult are:
There are still some things that behave the same as IPython.kernel:
# old
In [5]: pr = mec.pull('a', targets=[0,1], block=False)
In [6]: pr.r
Out[6]: [5, 5]
# new
In [5]: ar = dview.pull('a', targets=[0,1], block=False)
In [6]: ar.r
Out[6]: [5, 5]
The .r or .result property simply calls get(), waiting for and returning the result.
See also:
AsyncResult details
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Configuring IPython
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Many of IPython’s classes have configurable attributes (see IPython options for the list). These can be
configured in several ways.
If you leave out the profile name, the files will be created for the default profile (see Profiles). These will
typically be located in ~/.ipython/profile_default/, and will be named ipython_config.
py, ipython_notebook_config.py, etc. The settings in ipython_config.py apply to all
IPython commands.
The files typically start by getting the root config object:
415
IPython Documentation, Release 3.0.0-dev
c = get_config()
c.InteractiveShell.automagic = False
c.InteractiveShellApp.extensions.append('Cython')
New in version 2.0: list, dict and set methods for config values
# sample ipython_config.py
c = get_config()
c.TerminalIPythonApp.display_banner = True
c.InteractiveShellApp.log_level = 20
c.InteractiveShellApp.extensions = [
'myextension'
]
c.InteractiveShellApp.exec_lines = [
'import numpy',
'import scipy'
]
c.InteractiveShellApp.exec_files = [
'mycode.py',
'fancy.ipy'
]
c.InteractiveShell.autoindent = True
c.InteractiveShell.colors = 'LightBG'
c.InteractiveShell.confirm_exit = False
c.InteractiveShell.deep_reload = True
c.InteractiveShell.editor = 'nano'
c.InteractiveShell.xmode = 'Context'
c.PrefilterManager.multi_line_specials = True
c.AliasManager.user_aliases = [
('la', 'ls -al')
]
Every configurable value can be set from the command line, using this syntax:
ipython --ClassName.attribute=value
Many frequently used options have short aliases and flags, such as --matplotlib (to integrate with a
matplotlib GUI event loop) or --pdb (automatic post-mortem debugging of exceptions).
To see all of these abbreviated options, run:
ipython --help
ipython notebook --help
# etc.
Options specified at the command line, in either format, override options set in a configuration file.
You can also modify config from inside IPython, using a magic command:
At present, this only affects the current session - changes you make to config are not saved anywhere. Also,
some options are only read when IPython starts, so they can’t be changed like this.
Profiles
IPython can use multiple profiles, with separate configuration and history. By default, if you don’t specify a
profile, IPython always runs in the default profile. To use a new profile:
Profiles are typically stored in The IPython directory, but you can also keep a profile in the current working
directory, for example to distribute it with a project. To find a profile directory on the filesystem:
IPython stores its files—config, command history and extensions—in the directory ~/.ipython/ by de-
fault.
IPYTHONDIR
If set, this environment variable should be the path to a directory, which IPython will use for user data.
IPython will create it if it does not exist.
--ipython-dir=<path>
This command line option can also be used to override the default IPython directory.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
IPython options
Any of the options listed here can be set in config files, at the command line, or from inside IPython. See
Setting configurable options for details.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Prompts
In the terminal, the format of the input and output prompts can be customised. This does not currently affect
other frontends.
The following codes in the prompt string will be substituted into the prompt string:
Short Long Notes
%n,\# {color.number}{count}{color.prompt} history counter with bolding
\N {count} history counter without bolding
\D {dots} series of dots the same width as the history counter
\T {time} current time
\w {cwd} current working directory
\W {cwd_last} basename of CWD
\Xn {cwd_x[n]} Show the last n terms of the CWD. n=0 means show
all.
\Yn {cwd_y[n]} Like Xn, but show ‘~’ for $HOME
\h hostname, up to the first ‘.’
\H full hostname
\u username (from the $USER environment variable)
\v IPython version
\$ root symbol (“$” for normal user or “#” for root)
\\ escaped ‘\’
\n newline
\r carriage return
n/a {color.<Name>} set terminal colour - see below for list of names
Available colour names are: Black, BlinkBlack, BlinkBlue, BlinkCyan, BlinkGreen, BlinkLightGray,
BlinkPurple, BlinkRed, BlinkYellow, Blue, Brown, Cyan, DarkGray, Green, LightBlue, LightCyan,
LightGray, LightGreen, LightPurple, LightRed, Purple, Red, White, Yellow. The selected colour scheme
also defines the names prompt and number. Finally, the name normal resets the terminal to its default colour.
So, this config:
c.PromptManager.in_template = "{color.LightGreen}{time}{color.Yellow} \u
˓→{color.normal}>>>"
will produce input prompts with the time in light green, your username in yellow, and a >>> prompt in the
default terminal colour.
Terminal Colors
The default IPython configuration has most bells and whistles turned on (they’re pretty safe). But there’s
one that may cause problems on some systems: the use of color on screen for displaying information.
This is very useful, since IPython can show prompts and exception tracebacks with various colors, display
syntax-highlighted source code, and in general make it easier to visually parse information.
The following terminals seem to handle the color sequences fine:
• Linux main text console, KDE Konsole, Gnome Terminal, E-term, rxvt, xterm.
• CDE terminal (tested under Solaris). This one boldfaces light colors.
• (X)Emacs buffers. See the (X)Emacs section for more details on using IPython with (X)Emacs.
• A Windows (XP/2k) command prompt with pyreadline.
• A Windows (XP/2k) CygWin shell. Although some users have reported problems; it is not clear
whether there is an issue for everyone or only under specific configurations. If you have full color
support under cygwin, please post to the IPython mailing list so this issue can be resolved for all users.
These have shown problems:
• Windows command prompt in WinXP/2k logged into a Linux machine via telnet or ssh.
• Windows native command prompt in WinXP/2k, without Gary Bishop’s extensions. Once Gary’s
readline library is installed, the normal WinXP/2k command prompt works perfectly.
Currently the following color schemes are available:
• NoColor: uses no color escapes at all (all escapes are empty ‘’ ‘’ strings). This ‘scheme’ is thus fully
safe to use in any terminal.
• Linux: works well in Linux console type environments: dark background with light fonts. It uses
bright colors for information, so it is difficult to read if you have a light colored background.
• LightBG: the basic colors are similar to those in the Linux scheme but darker. It is easy to read in
terminals with light backgrounds.
IPython uses colors for two main groups of things: prompts and tracebacks which are directly printed to the
terminal, and the object introspection system which passes large sets of data through a pager.
If you are seeing garbage sequences in your terminal and no colour, you may need to disable colours: run
%colors NoColor inside IPython, or add this to a config file:
c.InteractiveShell.colors = 'NoColor'
On some systems, the default pager has problems with ANSI colour codes. To configure your default pager
to allow these:
1. Set the environment PAGER variable to less.
2. Set the environment LESS variable to -r (plus any other options you always want to pass to less by
default). This tells less to properly interpret control sequences, which is how color information is
given to your terminal.
Editor configuration
Vim
(X)Emacs
If you are a dedicated Emacs user, and want to use Emacs when IPython’s %edit magic command is called
you should set up the Emacs server so that new requests are handled by the original process. This means that
almost no time is spent in handling the request (assuming an Emacs process is already running). For this to
work, you need to set your EDITOR environment variable to ‘emacsclient’. The code below, supplied by
Francois Pinard, can then be used in your .emacs file to enable the server:
(defvar server-buffer-clients)
(when (and (fboundp 'server-start) (string-equal (getenv "TERM") 'xterm))
(server-start)
(defun fp-kill-server-with-buffer-routine ()
(and server-buffer-clients (server-done)))
(add-hook 'kill-buffer-hook 'fp-kill-server-with-buffer-routine))
Thanks to the work of Alexander Schmolck and Prabhu Ramachandran, currently (X)Emacs and IPython
get along very well in other ways.
Note: You will need to use a recent enough version of python-mode.el, along with the file ipython.
el. You can check that the version you have of python-mode.el is new enough by either looking at the
revision number in the file itself, or asking for it in (X)Emacs via M-x py-version. Versions 4.68 and
newer contain the necessary fixes for proper IPython support.
The file ipython.el is included with the IPython distribution, in the directory docs/emacs. Once you
put these files in your Emacs path, all you need in your .emacs file is:
(require 'ipython)
This should give you full support for executing code snippets via IPython, opening IPython as your Python
shell via C-c !, etc.
You can customize the arguments passed to the IPython instance at startup by setting the
py-python-command-args variable. For example, to start always with matplotlib integration
and hardcoded light-background colors, you can use:
If you happen to get garbage instead of colored prompts as described in the previous section, you may need
to set also in your .emacs file:
(setq ansi-color-for-comint-mode t)
See also:
Overview of the IPython configuration system Technical details of the config system.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
IPython extensions
A level above configuration are IPython extensions, Python modules which modify the behaviour of the
shell. They are referred to by an importable module name, and can be placed anywhere you’d normally
import from, or in .ipython/extensions/.
Getting extensions
A few important extensions are bundled with IPython. Others can be found on the extensions index on the
wiki, and the Framework :: IPython tag on PyPI.
Extensions on PyPI can be installed using pip, like any other Python package. Other simple extensions
can be installed with the %install_ext magic. The latter does no validation, so be careful using it on
untrusted networks like public wifi.
Using extensions
c.InteractiveShellApp.extensions = [
'myextension'
]
Writing extensions
An IPython extension is an importable Python module that has a couple of special functions to load and
unload it. Here is a template:
# myextension.py
def load_ipython_extension(ipython):
# The `ipython` argument is the currently active `InteractiveShell`
# instance, which can be used in any way. This allows you to register
# new magics or aliases, for example.
def unload_ipython_extension(ipython):
# If you want your extension to be unloadable, put that logic here.
This load_ipython_extension() function is called after your extension is imported, and the cur-
rently active InteractiveShell instance is passed as the only argument. You can do anything you
want with IPython at that point.
load_ipython_extension() will be called again if you load or reload the extension again. It is up to
the extension author to add code to manage that.
Useful InteractiveShell methods include register_magic_function(), push() (to add
variables to the user namespace) and drop_by_id() (to remove variables on unloading).
See also:
Defining custom magics
You can put your extension modules anywhere you want, as long as they can be imported by Python’s
standard import mechanism. However, to make it easy to write extensions, you can also put your extensions
in extensions/ within the IPython directory. This directory is added to sys.path automatically.
When your extension is ready for general use, please add it to the extensions index. We also encourage you
to upload it to PyPI and use the Framework :: IPython classifier, so that users can install it with
standard packaging tools.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
autoreload
In [2]: %autoreload 2
In [4]: some_function()
Out[4]: 42
In [6]: some_function()
Out[6]: 43
The module was reloaded without reloading it explicitly, and the object imported with from foo import
... was also updated.
Usage
Caveats
Reloading Python modules in a reliable way is in general difficult, and unexpected things may occur.
%autoreload tries to work around common pitfalls by replacing function code objects and parts of classes
previously in the module with new versions. This makes the following things to work:
• Functions and classes imported via ‘from xxx import foo’ are upgraded to new versions when ‘xxx’
is reloaded.
• Methods and properties of classes are upgraded on reload, so that calling ‘c.foo()’ on an object ‘c’
created before the reload causes the new code for ‘foo’ to be executed.
Some of the known remaining caveats are:
• Replacing code objects does not always succeed: changing a @property in a class to an ordinary
method or a method to a member variable can cause problems (but in old objects only).
• Functions that are removed (eg. via monkey-patching) from a module before it is reloaded are not
upgraded.
• C extension modules cannot be reloaded, and so cannot be autoreloaded.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
cythonmagic
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
storemagic
c.StoreMagics.autorestore = True
StoreMagics.store(parameter_s=’‘)
Lightweight persistence for python variables.
Example:
In [1]: l = ['hello',10,'world']
In [2]: %store l
In [3]: exit
ville@badger:~$ ipython
In [1]: l
NameError: name 'l' is not defined
In [2]: %store -r
In [3]: l
Out[3]: ['hello', 10, 'world']
Usage:
•%store - Show list of all variables and their current values
•%store spam - Store the current value of the variable spam to disk
•%store -d spam - Remove the variable and its value from storage
•%store -z - Remove all variables from storage
•%store -r - Refresh all variables from store (overwrite current vals)
•%store -r spam bar - Refresh specified variables from store (delete current val)
•%store foo >a.txt - Store value of foo to new file a.txt
•%store foo >>a.txt - Append value of foo to file a.txt
It should be noted that if you change the value of a variable, you need to %store it again if you want
to persist the new value.
Note also that the variables will need to be pickleable; most basic python types can be safely %store’d.
Also aliases can be %store’d across sessions.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
sympyprinting
Usage
Once the extension is loaded, Sympy Basic objects are automatically pretty-printed.
As of SymPy 0.7.2, maintenance of this extension has moved to SymPy under
sympy.interactive.ipythonprinting, any modifications to account for changes to SymPy should be
submitted to SymPy rather than changed here. This module is maintained here for backwards compatablitiy
with old SymPy versions.
• octavemagic used to be bundled, but is now part of oct2py. Use %load_ext oct2py.
ipython to load it.
• rmagic is now part of rpy2. Use %load_ext rpy2.ipython to load it, and see rpy2.
ipython.rmagic for details of how to use it.
• cythonmagic``used to be bundled, but is now part of `cython
<https://github.com/cython/cython/>`_ Use ``%load_ext Cython to load it.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Tab completion
To change the attributes displayed by tab-completing your object, define a __dir__(self) method for
it. For more details, see the documentation of the built-in dir() function.
Rich display
The notebook and the Qt console can display richer representations of objects. To use this, you can de-
fine any of a number of _repr_*_() methods. Note that these are surrounded by single, not double
underscores.
Both the notebook and the Qt console can display svg, png and jpeg representations. The notebook can
also display html, javascript, and latex. If the methods don’t exist, or return None, it falls back to
a standard repr().
For example:
class Shout(object):
def __init__(self, text):
self.text = text
def _repr_html_(self):
return "<h1>" + self.text + "</h1>"
Rarely, you might want to display a different traceback with an exception - IPython’s own par-
allel computing framework does this to display errors from the engines. To do this, define a
_render_traceback_(self) method which returns a list of strings, each containing one line of the
traceback.
Please be conservative in using this feature; by replacing the default traceback you may hide important
information from the user.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
There are two main ways to define your own magic functions: from standalone functions and by inheriting
from a base class provided by IPython: IPython.core.magic.Magics. Below we show code you
can place in a file that you load from your configuration, such as any file in the startup subdirectory of
your default IPython profile.
First, let us see the simplest case. The following shows how to create a line magic, a cell one and one that
works in both modes, using just plain functions:
@register_line_magic
def lmagic(line):
"my line magic"
return line
@register_cell_magic
def cmagic(line, cell):
"my cell magic"
return line, cell
@register_line_cell_magic
def lcmagic(line, cell=None):
"Magic that works both as %lcmagic and as %%lcmagic"
if cell is None:
print("Called as line magic")
return line
else:
print("Called as cell magic")
return line, cell
You can also create magics of all three kinds by inheriting from the IPython.core.magic.Magics
class. This lets you create magics that can potentially hold state in between calls, and that have full access
to the main IPython object:
# This code can be put in any Python module, it does not require IPython
# itself to be running already. It only creates the magics subclass but
# doesn't instantiate it yet.
from __future__ import print_function
from IPython.core.magic import (Magics, magics_class, line_magic,
cell_magic, line_cell_magic)
@line_magic
def lmagic(self, line):
"my line magic"
print("Full access to the main IPython object:", self.shell)
print("Variables in the user namespace:", list(self.shell.user_ns.
˓→keys()))
return line
@cell_magic
def cmagic(self, line, cell):
"my cell magic"
return line, cell
@line_cell_magic
def lcmagic(self, line, cell=None):
"Magic that works both as %lcmagic and as %%lcmagic"
if cell is None:
print("Called as line magic")
return line
else:
print("Called as cell magic")
return line, cell
# In order to actually use these magics, you must register them with a
# running IPython. This code must be placed in a file that is loaded once
# IPython is up and running:
ip = get_ipython()
# You can register the class itself without instantiating it. IPython will
# call the default constructor on it.
ip.register_magics(MyMagics)
If you want to create a class with a different constructor that holds additional state, then you should always
call the parent constructor and instantiate the class yourself before registration:
@magics_class
class StatefulMagics(Magics):
"Magics that hold additional state"
# etc...
ip = get_ipython()
magics = StatefulMagics(ip, some_data)
ip.register_magics(magics)
In earlier versions, IPython had an API for the creation of line magics (cell magics did not exist at the time)
that required you to create functions with a method-looking signature and to manually pass both the function
and the name. While this API is no longer recommended, it remains indefinitely supported for backwards
compatibility purposes. With the old API, you’d create a magic as follows:
ip = get_ipython()
# Declare this function as the magic %mycommand
ip.define_magic('mycommand', func)
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
IPython extends Python syntax to allow things like magic commands, and help with the ? syntax. There are
several ways to customise how the user’s input is processed into Python code to be executed.
These hooks are mainly for other projects using IPython as the core of their interactive interface. Using
them carelessly can easily break IPython!
When the user enters a line of code, it is first processed as a string. By the end of this stage, it must be valid
Python syntax.
These transformers all subclass IPython.core.inputtransformer.InputTransformer, and
are used by IPython.core.inputsplitter.IPythonInputSplitter.
These transformers act in three groups, stored separately as lists of instances in attributes of
IPythonInputSplitter:
• physical_line_transforms act on the lines as the user enters them. For example, these strip
Python prompts from examples pasted in.
• logical_line_transforms act on lines as connected by explicit line continuations, i.e. \ at
the end of physical lines. They are skipped inside multiline Python statements. This is the point where
IPython recognises %magic commands, for instance.
• python_line_transforms act on blocks containing complete Python statements. Multi-line
strings, lists and function calls are reassembled before being passed to these, but note that function
and class definitions are still a series of separate statements. IPython does not use any of these by
default.
An InteractiveShell instance actually has two IPythonInputSplitter instances, as the attributes
input_splitter, to tell when a block of input is complete, and input_transformer_manager,
to transform complete cells. If you add a transformer, you should make sure that it gets added to both, e.g.:
ip.input_splitter.logical_line_transforms.append(my_transformer())
ip.input_transformer_manager.logical_line_transforms.append(my_transformer())
These transformers may raise SyntaxError if the input code is invalid, but in most cases it is clearer to
pass unrecognised code through unmodified and let Python’s own parser decide whether it is valid.
Changed in version 2.0: Added the option to raise SyntaxError.
Stateless transformations
The simplest kind of transformations work one line at a time. Write a function which takes a line and returns
a line, and decorate it with StatelessInputTransformer.wrap():
@StatelessInputTransformer.wrap
def my_special_commands(line):
if line.startswith("¬"):
return "specialcommand(" + repr(line) + ")"
return line
Coroutine transformers
More advanced transformers can be written as coroutines. The coroutine will be sent each line in turn,
followed by None to reset it. It can yield lines, or None if it is accumulating text to yield at a later point.
When reset, it should give up any code it has accumulated.
This code in IPython strips a constant amount of leading indentation from each line in a cell:
@CoroutineInputTransformer.wrap
def leading_indent():
"""Remove leading indentation.
If the first line starts with a spaces or tabs, the same whitespace will
˓→ be
removed from each following line until it is reset.
"""
space_re = re.compile(r'^[ \t]+')
line = ''
while True:
line = (yield line)
if line is None:
continue
m = space_re.match(line)
if m:
space = m.group(0)
while line is not None:
if line.startswith(space):
line = line[len(space):]
line = (yield line)
else:
# No leading spaces - wait for reset
while line is not None:
line = (yield line)
leading_indent.look_in_string = True
Token-based transformers
There is an experimental framework that takes care of tokenizing and untokenizing lines of code. De-
fine a function that accepts a list of tokens, and returns an iterable of output tokens, and decorate it with
TokenInputTransformer.wrap(). These should only be used in python_line_transforms.
AST transformations
After the code has been parsed as Python syntax, you can use Python’s powerful Abstract Syntax Tree tools to
modify it. Subclass ast.NodeTransformer, and add an instance to shell.ast_transformers.
This example wraps integer literals in an Integer class, which is useful for mathematical frameworks that
want to handle e.g. 1/3 as a precise fraction:
class IntegerWrapper(ast.NodeTransformer):
"""Wraps all integers in a call to Integer()"""
def visit_Num(self, node):
if isinstance(node.n, int):
return ast.Call(func=ast.Name(id='Integer', ctx=ast.Load()),
args=[node], keywords=[])
return node
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Registering callbacks
Extension code can register callbacks functions which will be called on specific events within the IPython
code. You can see the current list of available callbacks, and the parameters that will be passed with each,
def pre_execute(self):
self.last_x = self.shell.user_ns.get('x', None)
def post_execute(self):
if self.shell.user_ns.get('x', None) != self.last_x:
print("x changed!")
def load_ipython_extension(ip):
vw = VarWatcher(ip)
ip.events.register('pre_execute', vw.pre_execute)
ip.events.register('post_execute', vw.post_execute)
Note: This API is experimental in IPython 2.0, and may be revised in future versions.
See also:
Module IPython.core.hooks The older ‘hooks’ system allows end users to customise some parts of
IPython’s behaviour.
Custom input transformation By registering input transformers that don’t change code, you can monitor
what is being executed.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
When the user types %gui qt, IPython integrates itself with the Qt event loop, so you can use both a GUI
and an interactive prompt together. IPython supports a number of common GUI toolkits, but from IPython
3.0, it is possible to integrate other event loops without modifying IPython itself.
Terminal IPython handles event loops very differently from the IPython kernel, so different steps are needed
to integrate with each.
In the terminal, IPython uses a blocking Python function to wait for user input. However, the Python C API
provides a hook, PyOS_InputHook(), which is called frequently while waiting for input. This can be
set to a function which briefly runs the event loop and then returns.
IPython provides Python level wrappers for setting and resetting this hook. To use them, subclass
IPython.lib.inputhook.InputHookBase, and define an enable(app=None) method, which
initialises the event loop and calls self.manager.set_inputhook(f) with a function which will
briefly run the event loop before exiting. Decorate the class with a call to IPython.lib.inputhook.
register():
@register('clutter')
class ClutterInputHook(InputHookBase):
def enable(self, app=None):
self.manager.set_inputhook(inputhook_clutter)
You can also optionally define a disable() method, taking no arguments, if there are extra steps needed
to clean up. IPython will take care of resetting the hook, whether or not you provide a disable method.
The simplest way to define the hook function is just to run one iteration of the event loop, or to run until
no events are pending. Most event loops provide some mechanism to do one of these things. However, the
GUI may lag slightly, because the hook is only called every 0.1 seconds. Alternatively, the hook can keep
running the event loop until there is input ready on stdin. IPython provides a function to facilitate this:
IPython.lib.inputhook.stdin_ready()
Returns True if there is something ready to read on stdin.
If this is the case, the hook function should return immediately.
This is implemented for Windows and POSIX systems - on other platforms, it always returns True, so
that the hook always gives Python a chance to check for input.
The kernel runs its own event loop, so it’s simpler to integrate with others. IPython allows the
other event loop to take control, but it must call IPython.kernel.zmq.kernelbase.Kernel.
do_one_iteration() periodically.
To integrate with this, write a function that takes a single argument, the IPython kernel instance, arranges for
your event loop to call kernel.do_one_iteration() at least every kernel._poll_interval
seconds, and starts the event loop.
Decorate this function with IPython.kernel.zmq.eventloops.register_integration(),
passing in the names you wish to register it for. Here is a slightly simplified version of the Tkinter integration
already included in IPython:
@register_integration('tk')
def loop_tk(kernel):
"""Start a kernel with the Tk event loop."""
from tkinter import Tk
# Tk uses milliseconds
poll_interval = int(1000*kernel._poll_interval)
# For Tkinter, we create a Tk object and call its withdraw method.
class Timer(object):
def on_timer(self):
self.func()
self.app.after(poll_interval, self.on_timer)
def start(self):
self.on_timer() # Call it once to get things going.
self.app.mainloop()
kernel.timer = Timer(kernel.do_one_iteration)
kernel.timer.start()
Some event loops can go one better, and integrate checking for messages on the kernel’s ZMQ sockets,
making the kernel more responsive than plain polling. How to do this is outside the scope of this document;
if you are interested, look at the integration with Qt in IPython.kernel.zmq.eventloops.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Terminal IPython
When you type ipython, you get the original IPython interface, running in the terminal. It does something
like this:
while True:
code = input(">>> ")
exec(code)
Of course, it’s much more complex, because it has to deal with multi-line code, tab completion using
readline, magic commands, and so on. But the model is like that: prompt the user for some code,
437
IPython Documentation, Release 3.0.0-dev
and when they’ve entered it, exec it in the same process. This model is often called a REPL, or Read-Eval-
Print-Loop.
All the other interfaces—the Notebook, the Qt console, ipython console in the terminal, and third
party interfaces—use the IPython Kernel. This is a separate process which is responsible for running user
code, and things like computing possible completions. Frontends communicate with it using JSON messages
sent over ZeroMQ sockets; the protocol they use is described in Messaging in IPython.
The core execution machinery for the kernel is shared with terminal IPython:
A kernel process can be connected to more than one frontend simultaneously. In this case, the different
frontends will have access to the same variables.
This design was intended to allow easy development of different frontends based on the same kernel, but
it also made it possible to support new languages in the same frontends, by developing kernels in those
languages, and we are refining IPython to make that more practical.
Today, there are two ways to develop a kernel for another language. Wrapper kernels reuse the commu-
nications machinery from IPython, and implement only the core execution part. Native kernels implement
execution and communications in the target language:
Wrapper kernels are easier to write quickly for languages that have good Python wrappers, like oc-
tave_kernel, or languages where it’s impractical to implement the communications machinery, like
bash_kernel. Native kernels are likely to be better maintained by the community using them, like IJulia
or IHaskell.
See also:
Making kernels for IPython
Making simple Python wrapper kernels
Notebooks
The Notebook frontend does something extra. In addition to running your code, it stores code and output,
together with markdown notes, in an editable document called a notebook. When you save it, this is sent
from your browser to the notebook server, which saves it on disk as a JSON file with a .ipynb extension.
The notebook server, not the kernel, is responsible for saving and loading notebooks, so you can edit note-
books even if you don’t have the kernel for that language—you just won’t be able to run code. The kernel
doesn’t know anything about the notebook document: it just gets sent cells of code to execute when the user
runs them.
The Nbconvert tool in IPython converts notebook files to other formats, such as HTML, LaTeX, or reStruc-
turedText. This conversion goes through a series of steps:
1. Preprocessors modify the notebook in memory. E.g. ExecutePreprocessor runs the code in the note-
book and updates the output.
2. An exporter converts the notebook to another file format. Most of the exporters use templates for this.
3. Postprocessors work on the file produced by exporting.
The nbviewer website uses nbconvert with the HTML exporter. When you give it a URL, it fetches the
notebook from that URL, converts it to HTML, and serves that HTML to you.
IPython.parallel
IPython also includes a parallel computing framework, IPython.parallel. This allows you to control
many individual engines, which are an extended version of the IPython kernel described above. For more
details, see Using IPython for parallel computing.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Messaging in IPython
Versioning
The IPython message specification is versioned independently of IPython. The current version of the speci-
fication is 5.0.
Introduction
This document explains the basic communications design and messaging specification for how the various
IPython objects interact over a network transport. The current implementation uses the ZeroMQ library for
messaging within and between hosts.
Note: This document should be considered the authoritative description of the IPython messaging protocol,
and all developers are strongly encouraged to keep it updated as the implementation evolves, so that we have
a single common reference for all protocol details.
Note: Not all of these have yet been fully fleshed out, but the key ones are, see kernel and frontend files for
actual implementation details.
{
# The message header contains a pair of unique identifiers for the
# originating session and the actual message id, in addition to the
# username for the process that generated the message. This is useful in
# collaborative settings where multiple users may be interacting with the
# same kernel simultaneously, so that frontends can label the various
# messages in a meaningful way.
'header' : {
'msg_id' : uuid,
'username' : str,
'session' : uuid,
# All recognized message type strings are listed below.
'msg_type' : str,
This message format exists at a high level, but does not describe the actual implementation at the wire level
in zeromq. The canonical implementation of the message spec is our Session class.
Note: This section should only be relevant to non-Python consumers of the protocol. Python con-
sumers should simply import and use IPython’s own implementation of the wire protocol in the IPython.
kernel.zmq.session.Session object.
[
b'u-u-i-d', # zmq identity(ies)
b'<IDS|MSG>', # delimiter
b'baddad42', # HMAC signature
b'{header}', # serialized header dict
b'{parent_header}', # serialized parent header dict
b'{metadata}', # serialized metadata dict
b'{content}, # serialized content dict
b'blob', # extra raw data buffer(s)
...
]
The front of the message is the ZeroMQ routing prefix, which can be zero or more socket identities.
This is every piece of the message prior to the delimiter key <IDS|MSG>. In the case of IOPub, there
should be just one prefix component, which is the topic for IOPub subscribers, e.g. execute_result,
display_data.
Note: In most cases, the IOPub topics are irrelevant and completely ignored, because frontends just sub-
scribe to all topics. The convention used in the IPython kernel is to use the msg_type as the topic, and
After the delimiter is the HMAC signature of the message, used for authentication. If authentication is dis-
abled, this should be an empty string. By default, the hashing function used for computing these signatures
is sha256.
Note: To disable authentication and signature checking, set the key field of a connection file to an empty
string.
# once:
digester = HMAC(key, digestmod=hashlib.sha256)
After the signature is the actual message, always in four frames of bytes. The four dictionaries that compose
a message are serialized separately, in the order of header, parent header, metadata, and content. These can
be serialized by any function that turns a dict into bytes. The default and most common serialization is
JSON, but msgpack and pickle are common alternatives.
After the serialized dicts are zero to many raw data buffers, which can be used by message types that support
binary data (mainly apply and data_pub).
As messages are dicts, they map naturally to a func(**kw) call form. We should develop, at a few key
points, functional forms of all the requests that take arguments in this manner and automatically construct
the necessary dict for sending.
In addition, the Python implementation of the message specification extends messages upon deserialization
to the following form for convenience:
{
'header' : dict,
# The msg's unique identifier and type are always stored in the header,
# but the Python implementation copies them to the top level.
'msg_id' : uuid,
'msg_type' : str,
'parent_header' : dict,
'content' : dict,
'metadata' : dict,
}
All messages sent to or received by any IPython process should have this extended structure.
Execute
This message type is used by frontends to ask the kernel to execute code on behalf of the user, in a namespace
reserved to the user’s variables (and thus separate from the kernel’s own internal code and variables).
Message type: execute_request:
content = {
# Source code to be executed by the kernel, one or more lines.
'code' : str,
# See the display_data content for the structure of the representation data.
'user_expressions' : dict,
{
'status' : 'error',
'ename' : 'NameError',
'evalue' : 'foo',
'traceback' : ...
}
Note: In order to obtain the current execution counter for the purposes of displaying input prompts, fron-
tends may make an execution request with an empty code string and silent=True.
Upon completion of the execution request, the kernel always sends a reply, with a status code indicating
what happened and additional data depending on the outcome. See below for the possible return codes and
associated data.
See also:
Execution semantics in the IPython kernel
The kernel should have a single, monotonically increasing counter of all execution requests that are made
with store_history=True. This counter is used to populate the In[n] and Out[n] prompts. The
value of this counter will be returned as the execution_count field of all execute_reply and
execute_input messages.
Execution results
content = {
# One of: 'ok' OR 'error' OR 'abort'
'status' : str,
# The global kernel counter that increases by one with each request that
# stores history. This will typically be used by clients to display
# prompt numbers to the user. If the request did not store history, this
˓→will
# be the current value of the counter in the kernel.
'execution_count' : int,
}
{
# 'payload' will be a list of payload dicts, and is optional.
# payloads are considered deprecated.
# The only requirement of each payload dict is that it have a 'source' key,
# which is a string classifying the payload (e.g. 'page').
'payload' : list(dict),
{
'ename' : str, # Exception name, as a string
'evalue' : str, # Exception value, as a string
When status is ‘abort’, there are for now no additional data fields. This happens when the kernel was
interrupted by a signal.
Payloads
Execution payloads
Payloads are considered deprecated, though their replacement is not yet implemented.
Payloads are a way to trigger frontend actions from the kernel. Current payloads:
page: display data in a pager.
Pager output is used for introspection, or other displayed information that’s not considered output. Pager
payloads are generally displayed in a separate pane, that can be viewed alongside code, and are not included
in notebook documents.
{
"source": "page",
# mime-bundle of data to display in the pager.
# Must include text/plain.
"data": mimebundle,
# line offset to start from
"start": int,
}
{
"source": "set_next_input",
# the text contents of the cell to create
"text": "some cell content",
# If true, replace the current cell in document UIs instead of inserting
# a cell. Ignored in console UIs.
"replace": bool,
}
{
"source": "edit",
"filename": "/path/to/file.py", # the file to edit
"line_number": int, # the line number to start with
}
{
"source": "ask_exit",
# whether the kernel should be left running, only closing the client
"keepkernel": bool,
}
Introspection
Code can be inspected to show useful information to the user. It is up to the Kernel to decide what informa-
tion should be displayed, and its formatting.
Message type: inspect_request:
content = {
# The code context in which introspection is requested
# this may be up to an entire multiline cell.
'code' : str,
# if available.
'detail_level' : 0 or 1,
}
content = {
# 'ok' if the request succeeded or 'error', with error information as in
˓→all other replies.
'status' : 'ok',
Completion
content = {
# The code context in which completion is requested
# this may be up to an entire multiline cell, such as
# 'foo = a.isal'
'code' : str,
Changed in version 5.0: line, block, and text keys are removed in favor of a single code for context.
Lexing is up to the kernel.
Message type: complete_reply:
content = {
# The list of all matches to the completion request, such as
# ['a.isalnum', 'a.isalpha'] for the above example.
'matches' : list,
# The range of text that should be replaced by the above matches when a
˓→completion is accepted.
# typically cursor_end is the same as cursor_pos in the request.
'cursor_start' : int,
'cursor_end' : int,
# Information that frontend plugins might use for extra display information
˓→about completions.
'metadata' : dict,
# status should be 'ok' unless an exception was raised during the request,
# in which case it should be 'error', along with the usual error message
˓→content
# in other messages.
'status' : 'ok'
}
History
For clients to explicitly request history from a kernel. The kernel has all the actual execution history stored
in a single location, so clients can request it from the kernel when needed.
Message type: history_request:
• content = {
# If True, return the raw input history, else the transformed input.
'raw' : bool,
content = {
# A list of 3 tuples, either:
# (session, line_number, input) or
# (session, line_number, (input, output)),
# depending on whether output was False or True, respectively.
'history' : list,
}
Code completeness
• invalid code will typically be sent for execution, so that the user sees the error soonest.
• unknown - if the kernel is not able to determine this. The frontend should also handle the kernel
not replying promptly. It may default to sending the code for execution, or it may implement simple
fallback heuristics for whether to execute the code (e.g. execute after a blank line).
Frontends may have ways to override this, forcing the code to be sent for execution or forcing a continuation
prompt.
Message type: is_complete_request:
content = {
# The code entered so far as a multiline string
'code' : str,
}
content = {
# One of 'complete', 'incomplete', 'invalid', 'unknown'
'status' : str,
Connect
When a client connects to the request/reply socket of the kernel, it can issue a connect request to get basic
information about the kernel, such as the ports the other ZeroMQ sockets are listening on. This allows
clients to only have to know about a single port (the shell channel) to connect to a kernel.
Message type: connect_request:
content = {
}
content = {
'shell_port' : int, # The port the shell ROUTER socket is listening on.
'iopub_port' : int, # The port the PUB socket is listening on.
'stdin_port' : int, # The port the stdin ROUTER socket is listening on.
'hb_port' : int, # The port the heartbeat socket is listening on.
}
Kernel info
If a client needs to know information about the kernel, it can make a request of the kernel’s information. This
message can be used to fetch core information of the kernel, including language (e.g., Python), language
version number and IPython version number, and the IPython message spec version number.
Message type: kernel_info_request:
content = {
}
content = {
# Version of messaging protocol.
# The first integer indicates major version. It is incremented when
# there is any backward incompatible change.
# The second integer indicates minor version. It is incremented when
# there is any backward compatible change.
'protocol_version': 'X.Y.Z',
Refer to the lists of available Pygments lexers and codemirror modes for those fields.
Changed in version 5.0: Versions changed from lists of integers to strings.
Changed in version 5.0: ipython_version is removed.
Changed in version 5.0: language_info, implementation, implementation_version,
banner and help_links keys are added.
Changed in version 5.0: language_version moved to language_info.version
Changed in version 5.0: language moved to language_info.name
Kernel shutdown
The clients can request the kernel to shut itself down; this is used in multiple cases:
• when the user chooses to close the client application via a menu or window control.
• when the user types ‘exit’ or ‘quit’ (or their uppercase magic equivalents).
• when the user chooses a GUI method (like the ‘Ctrl-C’ shortcut in the IPythonQt client) to force a
kernel restart to get a clean kernel without losing client-side state like history or inlined figures.
The client sends a shutdown request to the kernel, and once it receives the reply message (which is otherwise
empty), it can assume that the kernel has completed shutdown safely.
Upon their own shutdown, client applications will typically execute a last minute sanity check and forcefully
terminate any kernel that is still alive, to avoid leaving stray processes in the user’s machine.
Message type: shutdown_request:
content = {
'restart' : bool # whether the shutdown is final, or precedes a restart
}
content = {
'restart' : bool # whether the shutdown is final, or precedes a restart
}
Note: When the clients detect a dead kernel thanks to inactivity on the heartbeat socket, they simply
send a forceful process termination signal, since a dead process is unlikely to respond in any useful way to
messages.
content = {
# The name of the stream is one of 'stdout', 'stderr'
'name' : str,
Changed in version 5.0: ‘data’ key renamed to ‘text’ for conistency with the notebook format.
Display Data
This type of message is used to bring back data that should be displayed (text, html, svg, etc.) in the
frontends. This data is published to all frontends. Each message can have multiple representations of the
data; it is up to the frontend to decide which to use and how. A single message should contain all possible
representations of the same information. Each representation should be a JSON’able data structure, and
should be a valid MIME type.
Some questions remain about this design:
• Do we use this message type for execute_result/displayhook? Probably not, because the displayhook
also has to handle the Out prompt display. On the other hand we could put that information into the
metadata section.
Message type: display_data:
content = {
# The data dict contains key/value pairs, where the keys are MIME
# types and the values are the raw data of the representation in that
# format.
'data' : dict,
The metadata contains any metadata that describes the output. Global keys are assumed to apply to the
output as a whole. The metadata dict can also contain mime-type keys, which will be sub-dictionaries,
which are interpreted as applying only to output of that type. Third parties should put any data they write
into a single dict with a reasonably unique name to avoid conflicts.
The only metadata keys currently defined in IPython are the width and height of images:
metadata = {
'image/png' : {
'width': 640,
'height': 480
}
}
Changed in version 5.0: application/json data should be unpacked JSON data, not double-serialized
as a JSON string.
display_data lets you publish representations of data, such as images and html. This data_pub
message lets you publish actual raw data, sent via message buffers.
data_pub messages are constructed via the IPython.lib.datapub.publish_data() function:
content = {
# the keys of the data dict, after it has been unserialized
'keys' : ['a', 'b']
}
# the namespace dict will be serialized in the message buffers,
# which will have a length of at least one
buffers = [b'pdict', ...]
The interpretation of a sequence of data_pub messages for a given parent request should be to update a
single namespace with subsequent results.
Note: No frontends directly handle data_pub messages at this time. It is currently only used by the
client/engines in IPython.parallel, where engines may publish data to the Client, of which the Client
can then publish representations via display_data to various frontends.
Code inputs
To let all frontends know what code is being executed at any given time, these messages contain a re-
broadcast of the code portion of an execute_request, along with the execution_count.
Message type: execute_input:
content = {
'code' : str, # Source code to be executed, one or more lines
# The counter for this execution is also provided so that clients can
# display it, since IPython automatically creates variables called _iN
# (for input prompt In[N]).
'execution_count' : int
}
Execution results
Results of an execution are published as an execute_result. These are identical to display_data mes-
sages, with the addition of an execution_count key.
Results can have multiple simultaneous formats depending on its configuration. A plain text representation
should always be provided in the text/plain mime-type. Frontends are free to display any or all of these
according to its capabilities. Frontends should ignore mime-types they do not understand. The data itself is
any JSON object and depends on the format. It is often, but not always a string.
Message type: execute_result:
content = {
# The counter for this execution is also provided so that clients can
# display it, since IPython automatically creates variables called _N
# (for prompt N).
'execution_count' : int,
Execution errors
content = {
# Similar content to the execute_reply messages for the 'error' case,
# except the 'status' field is omitted.
}
Kernel status
This message type is used by frontends to monitor the status of the kernel.
Message type: status:
content = {
# When the kernel starts to handle a message, it will enter the 'busy'
# state and when it finishes, it will enter the 'idle' state.
# The kernel will publish state 'starting' exactly once at process
˓→startup.
execution_state : ('busy', 'idle', 'starting')
}
Changed in version 5.0: Busy and idle messages should be sent before/after handling every message, not
just execution.
Clear output
This message type is used to clear the output that is visible on the frontend.
Message type: clear_output:
content = {
# Wait to clear the output until new output is available. Clears the
# existing output immediately before the new output is displayed.
# Useful for creating simple animations with minimal flickering.
'wait' : bool,
}
Changed in version 4.1: stdout, stderr, and display boolean keys for selective clearing are removed,
and wait is added. The selective clearing keys are ignored in v4 and the default behavior remains the same,
so v4 clear_output messages will be safely handled by a v4.1 frontend.
This is a socket where the request/reply pattern goes in the opposite direction: from the kernel to a single
frontend, and its purpose is to allow raw_input and similar operations that read from sys.stdin on
the kernel to be fulfilled by the client. The request should be made to the frontend that made the execution
request that prompted raw_input to be called. For now we will keep these messages as simple as possible,
since they only mean to convey the raw_input(prompt) call.
Message type: input_request:
content = {
# the text to show at the prompt
'prompt' : str,
# Is the request for a password?
# If so, the frontend shouldn't echo input.
'password' : bool
}
When password is True, the frontend should not echo the input as it is entered.
Changed in version 5.0: password key added.
Note: The stdin socket of the client is required to have the same zmq IDENTITY as the client’s shell
socket. Because of this, the input_request must be sent with the same IDENTITY routing prefix as the
execute_reply in order for the frontend to receive the message.
Note: We do not explicitly try to forward the raw sys.stdin object, because in practice the kernel should
behave like an interactive program. When a program is opened on the console, the keyboard effectively
takes over the stdin file descriptor, and it can’t be used for raw reading anymore. Since the IPython kernel
effectively behaves like a console program (albeit one whose “keyboard” is actually living in a separate
process and transported over the zmq connection), raw stdin isn’t expected to be available.
Clients send ping messages on a REQ socket, which are echoed right back from the Kernel’s REP socket.
These are simple bytestrings, not full JSON messages described above.
Custom Messages
IPython 2.0 (msgspec v4.1) adds a messaging system for developers to add their own objects with Frontend
and Kernel-side components, and allow them to communicate with each other. To do this, IPython adds a
notion of a Comm, which exists on both sides, and can communicate in either direction.
These messages are fully symmetrical - both the Kernel and the Frontend can send each message, and no
messages expect a reply. The Kernel listens for these messages on the Shell channel, and the Frontend
listens for them on the IOPub channel.
Opening a Comm
{
'comm_id' : 'u-u-i-d',
'target_name' : 'my_comm',
'data' : {}
}
Every Comm has an ID and a target name. The code handling the message on the receiving side is responsi-
ble for maintaining a mapping of target_name keys to constructors. After a comm_open message has been
sent, there should be a corresponding Comm instance on both sides. The data key is always a dict and can
be any extra JSON information used in initialization of the comm.
If the target_name key is not found on the receiving side, then it should immediately reply with a
comm_close message to avoid an inconsistent state.
Comm Messages
Comm messages are one-way communications to update comm state, used for synchronizing widget state,
or simply requesting actions of a comm’s counterpart.
Essentially, each comm pair defines their own message specification implemented inside the data dict.
There are no expected replies (of course, one side can send another comm_msg in reply).
Message type: comm_msg:
{
'comm_id' : 'u-u-i-d',
'data' : {}
}
Since comms live on both sides, when a comm is destroyed the other side must be notified. This is done
with a comm_close message.
Message type: comm_close:
{
'comm_id' : 'u-u-i-d',
'data' : {}
}
Since comm messages can execute arbitrary user code, handlers should set the parent header and publish
status busy / idle, just like an execute request.
To Do
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
A ‘kernel’ is a program that runs and introspects the user’s code. IPython includes a kernel for Python code,
and people have written kernels for several other languages.
When IPython starts a kernel, it passes it a connection file. This specifies how to set up communications
with the frontend.
There are two options for writing a kernel:
1. You can reuse the IPython kernel machinery to handle the communications, and just describe how
to execute your code. This is much simpler if the target language can be driven from Python. See
Making simple Python wrapper kernels for details.
2. You can implement the kernel machinery in your target language. This is more work initially, but the
people using your kernel might be more likely to contribute to it if it’s in the language they know.
Connection files
Your kernel will be given the path to a connection file when it starts (see Kernel specs for how to specify
the command line arguments for your kernel). This file, which is accessible only to the current user, will
contain a JSON dictionary looking something like this:
{
"control_port": 50160,
"shell_port": 57503,
"transport": "tcp",
"signature_scheme": "hmac-sha256",
"stdin_port": 52597,
"hb_port": 42540,
"ip": "127.0.0.1",
"iopub_port": 40885,
"key": "a0436f6c-1916-498b-8eb9-e81ab9368e84"
}
The transport, ip and five _port fields specify five ports which the kernel should bind to using Ze-
roMQ. For instance, the address of the shell socket in the example above would be:
tcp://127.0.0.1:57503
Handling messages
After reading the connection file and binding to the necessary sockets, the kernel should go into an event
loop, listening on the hb (heartbeat), control and shell sockets.
Heartbeat messages should be echoed back immediately on the same socket - the frontend uses this to check
that the kernel is still alive.
Messages on the control and shell sockets should be parsed, and their signature validated. See The Wire
Protocol for how to do this.
The kernel will send messages on the iopub socket to display output, and on the stdin socket to prompt the
user for textual input.
See also:
Messaging in IPython Details of the different sockets and the messages that come over them
Creating Language Kernels for IPython A blog post by the author of IHaskell, a Haskell kernel
simple_kernel A simple example implementation of the kernel machinery in Python
Kernel specs
A kernel identifies itself to IPython by creating a directory, the name of which is used as an identifier for the
kernel. These may be created in a number of locations:
Unix Windows
System /usr/share/ipython/ %PROGRAMDATA%\ipython\kernels
kernels
/usr/local/share/
ipython/kernels
User ~/.ipython/kernels
The user location takes priority over the system locations, and the case of the names is ignored, so selecting
kernels works the same way whether or not the filesystem is case sensitive.
Inside the directory, the most important file is kernel.json. This should be a JSON serialised dictionary
containing the following keys and values:
• argv: A list of command line arguments used to start the kernel. The text {connection_file}
in any argument will be replaced with the path to the connection file.
• display_name: The kernel’s name as it should be displayed in the UI. Unlike the kernel name used
in the API, this can contain arbitrary unicode characters.
• env (optional): A dictionary of environment variables to set for the kernel. These will be added to the
current environment variables before the kernel is started.
For example, the kernel.json file for IPython looks like this:
{
"argv": ["python3", "-c", "from IPython.kernel.zmq.kernelapp import main;
˓→ main()",
"-f", "{connection_file}"],
"display_name": "IPython (Python 3)",
}
To use different kernels in the notebook, select a different kernel from the dropdown menu in the top-right
of the UI.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
You can now re-use the kernel machinery in IPython to easily make new kernels. This is useful for languages
that have Python bindings, such as Octave (via Oct2Py), or languages where the REPL can be controlled in
a tty using pexpect, such as bash.
See also:
bash_kernel A simple kernel for bash, written using this machinery
Required steps
implementation
implementation_version
language
language_version
banner
Information for Kernel info replies. ‘Implementation’ refers to the kernel (e.g. IPython), and
‘language’ refers to the language it interprets (e.g. Python). The ‘banner’ is displayed to the
user in console UIs before the first prompt. All of these values are strings.
language_info
Language information for Kernel info replies, in a dictionary. This should contain the key
mimetype with the mimetype of code in the target language (e.g. 'text/x-python'),
and file_extension (e.g. 'py'). It may also contain keys codemirror_mode and
pygments_lexer if they need to differ from language.
Other keys may be added to this later.
do_execute(code, silent, store_history=True, user_expressions=None, allow_stdin=False)
Execute user code.
Parameters
• code (str) – The code to be executed.
• silent (bool) – Whether to display output.
• store_history (bool) – Whether to record this code in history and in-
crease the execution count. If silent is True, this is implicitly False.
• user_expressions (dict) – Mapping of names to expressions to evaluate
after the code has run. You can ignore this if you need to.
• allow_stdin (bool) – Whether the frontend can provide input on request
(e.g. for Python’s raw_input()).
Your method should return a dict containing the fields described in Execution results. To display
output, it can send messages using send_response(). See Messaging in IPython for details
of the different message types.
Example
class EchoKernel(Kernel):
implementation = 'Echo'
implementation_version = '1.0'
language = 'no-op'
language_version = '0.1'
language_info = {'mimetype': 'text/plain'}
banner = "Echo kernel - as useful as a parrot"
if __name__ == '__main__':
from IPython.kernel.zmq.kernelapp import IPKernelApp
IPKernelApp.launch_instance(kernel_class=EchoKernel)
Optional steps
You can override a number of other methods to improve the functionality of your kernel. All of these
methods should return a dictionary as described in the relevant section of the messaging spec.
class MyKernel
do_complete(code, cusor_pos)
Code completion
Parameters
• code (str) – The code already present
• cursor_pos (int) – The position in the code where completion is requested
See also:
Completion messages
do_inspect(code, cusor_pos, detail_level=0)
Object introspection
Parameters
• code (str) – The code
• cursor_pos (int) – The position in the code where introspection is re-
quested
• detail_level (int) – 0 or 1 for more or less detail. In IPython, 1 gets the
source code.
See also:
Introspection messages
do_history(hist_access_type, output, raw, session=None, start=None, stop=None,
n=None, pattern=None, unique=False)
History access. Only the relevant parameters for the type of history request concerned will be
passed, so your method definition must have defaults for all the arguments shown with defaults
here.
See also:
History messages
do_is_complete(code)
Is code entered in a console-like interface complete and ready to execute, or should a continua-
tion prompt be shown?
Parameters code (str) – The code entered so far - possibly multiple lines
See also:
Code completeness messages
do_shutdown(restart)
Shutdown the kernel. You only need to handle your own clean up - the kernel machinery will
take care of cleaning up its own things before stopping.
Parameters restart (bool) – Whether the kernel will be started again afterwards
See also:
Kernel shutdown messages
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
for i in range(10):
i**2
exec An arbitrary amount of source code, this is how modules are compiled. sys.displayhook() is
never implicitly called.
eval A single expression that returns a value. sys.displayhook() is never implicitly called.
The code field is split into individual blocks each of which is valid for execution in ‘single’ mode, and
then:
• If there is only a single block: it is executed in ‘single’ mode.
• If there is more than one block:
– if the last one is a single line long, run all but the last in ‘exec’ mode and the very last one in
‘single’ mode. This makes it easy to type simple expressions at the end to see computed values.
– if the last one is no more than two lines long, run all but the last in ‘exec’ mode and the very last
one in ‘single’ mode. This makes it easy to type simple expressions at the end to see computed
values. - otherwise (last one is also multiline), run all in ‘exec’ mode
– otherwise (last one is also multiline), run all in ‘exec’ mode as a single unit.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
This is an extension of the messaging doc. Diagrams of the connections can be found in the parallel con-
nections doc.
ZMQ messaging is also used in the parallel computing IPython system. All messages to/from kernels remain
the same as the single kernel model, and are forwarded through a ZMQ Queue device. The controller
receives all messages and replies in these channels, and saves results for future use.
The Controller
The controller is the central collection of processes in the IPython parallel computing model. It has two
major components:
• The Hub
• A collection of Schedulers
The Hub
The Hub is the central process for monitoring the state of the engines, and all task requests and results. It
has no role in execution and does no relay of messages, so large blocking requests or database actions in the
Hub do not have the ability to impede job submission and results.
Registration (ROUTER)
The first function of the Hub is to facilitate and monitor connections of clients and engines. Both client and
engine registration are handled by the same socket, so only one ip/port pair is needed to connect any number
of connections and clients.
Engines register with the zmq.IDENTITY of their two DEALER sockets, one for the queue, which receives
execute requests, and one for the heartbeat, which is used to monitor the survival of the Engine process.
Message type: registration_request:
content = {
'uuid' : 'abcd-1234-...', # the zmq.IDENTITY of the engine's sockets
}
The Controller replies to an Engine’s registration request with the engine’s integer ID, and all the remaining
connection information for connecting the heartbeat process, and kernel queue socket(s). The message status
will be an error if the Engine requests IDs that already in use.
Message type: registration_reply:
content = {
'status' : 'ok', # or 'error'
# if ok:
'id' : 0, # int, the engine id
}
Clients use the same socket as engines to start their connections. Connection requests from clients need no
information:
Message type: connection_request:
content = {}
The reply to a Client registration request contains the connection information for the multiplexer and load
balanced queues, as well as the address for direct hub queries. If any of these addresses is None, that
functionality is not available.
Message type: connection_reply:
content = {
'status' : 'ok', # or 'error'
}
Heartbeat
The hub uses a heartbeat system to monitor engines, and track when they become unresponsive. As de-
scribed in messaging, and shown in connections.
Notification (PUB)
The hub publishes all engine registration/unregistration events on a PUB socket. This allows clients to have
up-to-date engine ID sets without polling. Registration notifications contain both the integer engine ID and
the queue ID, which is necessary for sending messages via the Multiplexer Queue and Control Queues.
Message type: registration_notification:
content = {
'id' : 0, # engine ID that has been registered
'uuid' : 'engine_id' # the IDENT for the engine's sockets
}
content = {
'id' : 0 # engine ID that has been unregistered
'uuid' : 'engine_id' # the IDENT for the engine's sockets
}
The hub monitors and logs all queue traffic, so that clients can retrieve past results or monitor pending tasks.
This information may reside in-memory on the Hub, or on disk in a database (SQLite and MongoDB are
currently supported). These requests are handled by the same socket as registration.
queue_request() requests can specify multiple engines to query via the targets element. A verbose
flag can be passed, to determine whether the result should be the list of msg_ids in the queue or simply
the length of each list.
Message type: queue_request:
content = {
'verbose' : True, # whether return should be lists themselves or just lens
'targets' : [0,3,1] # list of ints
}
The content of a reply to a queue_request() request is a dict, keyed by the engine IDs. Note that they
will be the string representation of the integer keys, since JSON cannot handle number keys. The three keys
of each dict are:
'completed' : messages submitted via any queue that ran on the engine
'queue' : jobs submitted via MUX queue, whose results have not been received
'tasks' : tasks that are known to have been submitted to the engine, but
have not completed. Note that with the pure zmq scheduler, this
˓→will
always be 0/[].
content = {
'status' : 'ok', # or 'error'
# if verbose=False:
'0' : {'completed' : 1, 'queue' : 7, 'tasks' : 0},
# if verbose=True:
'1' : {'completed' : ['abcd-...','1234-...'], 'queue' : ['58008-'], 'tasks
˓→' : []},
}
Clients can request individual results directly from the hub. This is primarily for gathering results of execu-
tions not submitted by the requesting client, as the client will have all its own results already. Requests are
made by msg_id, and can contain one or more msg_id. An additional boolean key ‘statusonly’ can be used
to not request the results, but simply poll the status of the jobs.
Message type: result_request:
content = {
'msg_ids' : ['uuid','...'], # list of strs
'targets' : [1,2,3], # list of int ids or uuids
'statusonly' : False, # bool
}
The result_request() reply contains the content objects of the actual execution reply messages. If
statusonly=True, then there will be only the ‘pending’ and ‘completed’ lists.
Message type: result_reply:
content = {
'status' : 'ok', # else error
# if ok:
'acbd-...' : msg, # the content dict is keyed by msg_ids,
# values are the result messages
# there will be none of these if `statusonly=True`
'pending' : ['msg_id','...'], # msg_ids still pending
'completed' : ['msg_id','...'], # list of completed msg_ids
}
buffers = ['bufs','...'] # the buffers that contained the results of the
˓→objects.
# this will be empty if no messages are complete, or
˓→if
# statusonly is True.
For memory management purposes, Clients can also instruct the hub to forget the results of messages. This
can be done by message ID or engine ID. Individual messages are dropped by msg_id, and all messages
completed on an engine are dropped by engine ID. This may no longer be necessary with the mongodb-
based message logging backend.
If the msg_ids element is the string 'all' instead of a list, then all completed results are forgotten.
Message type: purge_request:
content = {
'msg_ids' : ['id1', 'id2',...], # list of msg_ids or 'all'
'engine_ids' : [0,2,4] # list of engine IDs
}
The reply to a purge request is simply the status ‘ok’ if the request succeeded, or an explanation of why it
failed, such as requesting the purge of a nonexistent or pending message.
Message type: purge_reply:
content = {
'status' : 'ok', # or 'error'
}
Schedulers
content = {
'msg_id' : 'abcd-1234-...', # the msg's uuid
'engine_id' : '1234-abcd-...', # the destination engine's zmq.IDENTITY
}
apply()
In terms of message classes, the MUX scheduler and Task scheduler relay the exact same message types.
Their only difference lies in how the destination is selected.
The Namespace model suggests that execution be able to use the model:
which takes f, a function in the user’s namespace, and executes f(*args, **kwargs) on a remote
engine, returning the result (or, for non-blocking, information facilitating later retrieval of the result). This
model, unlike the execute message which just uses a code string, must be able to send arbitrary (pickleable)
Python objects. And ideally, copy as little data as we can. The buffers property of a Message was
introduced for this purpose.
metadata = {
'after' : ['msg_id',...], # list of msg_ids or output of Dependency.as_
˓→dict()
'follow' : ['msg_id',...], # list of msg_ids or output of Dependency.as_
˓→dict()
}
content = {}
buffers = ['...'] # at least 3 in length
# as built by build_apply_message(f,args,kwargs)
after/follow represent task dependencies. ‘after’ corresponds to a time dependency. The request will not
arrive at an engine until the ‘after’ dependency tasks have completed. ‘follow’ corresponds to a location
dependency. The task will be submitted to the same engine as these msg_ids (see Dependency docs for
details).
Message type: apply_reply:
content = {
'status' : 'ok' # 'ok' or 'error'
# other error info here, as in other messages
}
buffers = ['...'] # either 1 or 2 in length
# a serialization of the return value of f(*args,**kwargs)
# only populated if status is 'ok'
All engine execution and data movement is performed via apply messages.
Control Messages
Messages that interact with the engines, but are not meant to execute code, are submitted via the Control
queue. These messages have high priority, and are thus received and handled before any execution requests.
Clients may want to clear the namespace on the engine. There are no arguments nor information involved
in this request, so the content is empty.
Message type: clear_request:
content = {}
content = {
'status' : 'ok' # 'ok' or 'error'
# other error info here, as in other messages
}
Clients may want to abort tasks that have not yet run. This can by done by message id, or all enqueued
messages can be aborted if None is specified.
Message type: abort_request:
content = {
'msg_ids' : ['1234-...', '...'] # list of msg_ids or None
}
content = {
'status' : 'ok' # 'ok' or 'error'
# other error info here, as in other messages
}
The last action a client may want to do is shutdown the kernel. If a kernel receives a shutdown request, then
it aborts all queued messages, replies to the request, and exits.
Message type: shutdown_request:
content = {}
content = {
'status' : 'ok' # 'ok' or 'error'
# other error info here, as in other messages
}
Implementation
There are a few differences in implementation between the StreamSession object used in the newparallel
branch and the Session object, the main one being that messages are sent in parts, rather than as a single
serialized object. StreamSession objects also take pack/unpack functions, which are to be used when
serializing/deserializing objects. These can be any functions that translate to/from formats that ZMQ sockets
can send (buffers,bytes, etc.).
Split Sends
Previously, messages were bundled as a single json object and one call to socket.send_json(). Since
the hub inspects all messages, and doesn’t need to see the content of the messages, which can be large,
messages are now serialized and sent in pieces. All messages are sent in at least 4 parts: the header, the
parent header, the metadata and the content. This allows the controller to unpack and inspect the (always
small) header, without spending time unpacking the content unless the message is bound for the controller.
Buffers are added on to the end of the message, and can be any objects that present the buffer interface.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
This is a quick summary and illustration of the connections involved in the ZeroMQ based IPython cluster
for parallel computing.
All Connections
The IPython cluster consists of a Controller, and one or more each of clients and engines. The goal of
the Controller is to manage and monitor the connections and communications between the clients and the
engines. The Controller is no longer a single process entity, but rather a collection of processes - specifically
one Hub, and 4 (or more) Schedulers.
It is important for security/practicality reasons that all connections be inbound to the controller processes.
The arrows in the figures indicate the direction of the connection.
Fig. 8.1: All the connections involved in connecting one client to one engine.
The Controller consists of 1-5 processes. Central to the cluster is the Hub, which monitors engine state,
execution traffic, and handles registration and notification. The Hub includes a Heartbeat Monitor for keep-
ing track of engines that are alive. Outside the Hub are 4 Schedulers. These devices are very small pure-C
MonitoredQueue processes (or optionally threads) that relay messages very fast, but also send a copy of each
message along a side socket to the Hub. The MUX queue and Control queue are MonitoredQueue ØMQ
devices which relay explicitly addressed messages from clients to engines, and their replies back up. The
Balanced queue performs load-balancing destination-agnostic scheduling. It may be a MonitoredQueue de-
vice, but may also be a Python Scheduler that behaves externally in an identical fashion to MQ devices, but
with additional internal logic. stdout/err are also propagated from the Engines to the clients via a PUB/SUB
MonitoredQueue.
Registration
Fig. 8.2: Engines and Clients only need to know where the Query ROUTER is located to start connecting.
Once a controller is launched, the only information needed for connecting clients and/or engines is the
IP/port of the Hub’s ROUTER socket called the Registrar. This socket handles connections from both clients
and engines, and replies with the remaining information necessary to establish the remaining connections.
Clients use this same socket for querying the Hub for state information.
Heartbeat
The heartbeat process has been described elsewhere. To summarize: the Heartbeat Monitor publishes a
distinct message periodically via a PUB socket. Each engine has a zmq.FORWARDER device with a SUB
socket for input, and DEALER socket for output. The SUB socket is connected to the PUB socket labeled
ping, and the DEALER is connected to the ROUTER labeled pong. This results in the same message being
relayed back to the Heartbeat Monitor with the addition of the DEALER prefix. The Heartbeat Monitor
receives all the replies via an ROUTER socket, and identifies which hearts are still beating by the zmq.
IDENTITY prefix of the DEALER sockets, which information the Hub uses to notify clients of any changes
in the available engines.
Schedulers
Fig. 8.4: Control message scheduler on the left, execution (apply) schedulers on the right.
The controller has at least three Schedulers. These devices are primarily for relaying messages between
clients and engines, but the Hub needs to see those messages for its own purposes. Since no Python code
may exist between the two sockets in a queue, all messages sent through these queues (both directions) are
also sent via a PUB socket to a monitor, which allows the Hub to monitor queue traffic without interfering
with it.
For tasks, the engine need not be specified. Messages sent to the ROUTER socket from the client side
are assigned to an engine via ZMQ’s DEALER round-robin load balancing. Engine replies are directed to
specific clients via the IDENTITY of the client, which is received as a prefix at the Engine.
For Multiplexing, ROUTER is used for both in and output sockets in the device. Clients must specify the
destination by the zmq.IDENTITY of the ROUTER socket connected to the downstream end of the device.
At the Kernel level, both of these ROUTER sockets are treated in the same way as the REP socket in the
serial version (except using ZMQStreams instead of explicit sockets).
Execution can be done in a load-balanced (engine-agnostic) or multiplexed (engine-specified) manner. The
sockets on the Client and Engine are the same for these two actions, but the scheduler used determines
the actual behavior. This routing is done via the zmq.IDENTITY of the upstream sockets in each Moni-
toredQueue.
IOPub
On the kernels, stdout/stderr are captured and published via a PUB socket. These PUB sockets all connect to
a SUB socket input of a MonitoredQueue, which subscribes to all messages. They are then republished via
another PUB socket, which can be subscribed by the clients.
Client connections
The hub’s registrar ROUTER socket also listens for queries from clients as to queue status, and control
instructions. Clients connect to this socket via an DEALER during registration.
The Hub publishes all registration/unregistration events via a PUB socket. This allows clients to stay up to
date with what engines are available by subscribing to the feed with a SUB socket. Other processes could
selectively subscribe to just registration or unregistration events.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Fig. 8.7: Engine registration events are published via a PUB socket.
IPythonLexer & IPython3Lexer Lexers for pure IPython (python + magic/shell commands)
IPythonPartialTracebackLexer & IPythonTracebackLexer Supports 2.x and 3.x via the keyword
python3. The partial traceback lexer reads everything but the Python code appearing in a trace-
back. The full lexer combines the partial lexer with an IPython lexer.
IPythonConsoleLexer A lexer for IPython console sessions, with support for tracebacks. Supports 2.x and
3.x via the keyword python3.
IPyLexer A friendly lexer which examines the first line of text and from it, decides whether to use an
IPython lexer or an IPython console lexer. Supports 2.x and 3.x via the keyword python3.
Previously, the IPythonConsoleLexer class was available at IPython.sphinxext.
ipython_console_hightlight. It was inserted into Pygments’ list of available lexers under
the name ipython. It should be mentioned that this name is inaccurate, since an IPython console session
is not the same as IPython code (which itself is a superset of the Python language).
Now, the Sphinx extension inserts two console lexers into Pygments’ list of available lexers. Both are
IPyLexer instances under the names: ipython and ipython3. Although the names can be confusing
(as mentioned above), their continued use is, in part, to maintain backwards compatibility and to aid typical
usage. If a project needs to make Pygments aware of more than just the IPyLexer class, then one should not
make the IPyLexer class available under the name ipython and use ipy or some other non-conflicting
value.
Code blocks such as:
.. code-block:: ipython
In [1]: 2**2
Out[1]: 4
will continue to work as before, but now, they will also properly highlight tracebacks. For pure IPython
code, the same lexer will also work:
.. code-block:: ipython
x = ''.join(map(str, range(10)))
!echo $x
Since the first line of the block did not begin with a standard IPython console prompt, the entire block is
assumed to consist of IPython code instead.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
IPython.utils.py3compat.PY3
Boolean indicating whether we’re currently in Python 3.
Iterators
Many built in functions and methods in Python 2 come in pairs, one returning a list, and one returning an
iterator (e.g. range() and xrange()). In Python 3, there is usually only the iterator form, but it has the
name which gives a list in Python 2 (e.g. range()).
The way to write compatible code depends on what you need:
• A list, e.g. for serialisation, or to test if something is in it.
• Iteration, but it will never be used for very many items, so efficiency isn’t especially important.
• Iteration over many items, where efficiency is important.
list iteration (small) iteration(large)
list(range(n)) range(n) py3compat.xrange(n)
list(map(f, it)) map(f, it) –
list(zip(a, b)) zip(a, b) –
list(d.items()) d.items() py3compat.iteritems(d)
list(d.values()) d.values() py3compat.itervalues(d)
Iterating over a dictionary yields its keys, so there is rarely a need to use dict.keys() or dict.
iterkeys().
Avoid using map() to cause function side effects. This is more clearly written with a simple for loop.
IPython.utils.py3compat.xrange
A reference to range on Python 3, and xrange() on Python 2.
IPython.utils.py3compat.iteritems(d)
IPython.utils.py3compat.itervalues(d)
Iterate over (key, value) pairs of a dictionary, or just over values. iterkeys is not defined: iterating
over the dictionary yields its keys.
Several parts of the standard library have been renamed and moved. This is a short list of things that we’re
using. A couple of them have names in IPython.utils.py3compat, so you don’t need both imports
in each module that uses them.
Unicode
Always be explicit about what is text (unicode) and what is bytes. Encoding goes from unicode to bytes,
and decoding goes from bytes to unicode.
To open files for reading or writing text, use io.open(), which is the Python 3 builtin open function,
available on Python 2 as well. We almost always need to specify the encoding parameter, because the default
is platform dependent.
We have several helper functions for converting between string types. They all use the
encoding from IPython.utils.encoding.getdefaultencoding() by default, and the
errors='replace' option to do best-effort conversions for the user’s system.
IPython.utils.py3compat.unicode_to_str(u, encoding=None)
IPython.utils.py3compat.str_to_unicode(s, encoding=None)
Convert between unicode and the native str type. No-ops on Python 3.
IPython.utils.py3compat.str_to_bytes(s, encoding=None)
IPython.utils.py3compat.bytes_to_str(u, encoding=None)
Convert between bytes and the native str type. No-ops on Python 2.
IPython.utils.py3compat.cast_unicode(s, encoding=None)
IPython.utils.py3compat.cast_bytes(s, encoding=None)
Convert strings to unicode/bytes when they may be of either type.
IPython.utils.py3compat.cast_unicode_py2(s, encoding=None)
IPython.utils.py3compat.cast_bytes_py2(s, encoding=None)
Convert strings to unicode/bytes when they may be of either type on Python 2, but return them unal-
tered on Python 3 (where string types are more predictable).
IPython.utils.py3compat.unicode_type
A reference to str on Python 3, and to unicode on Python 2.
IPython.utils.py3compat.string_types
A tuple for isinstance checks: (str,) on Python 3, (str, unicode) on Python 2.
Relative imports
Print function
print(a, b)
print(foo, file=sys.stderr)
print(bar, baz, sep='\t', end='')
Metaclasses
The syntax for declaring a class with a metaclass is different in Python 2 and 3. A helper function works for
most cases:
IPython.utils.py3compat.with_metaclass()
Create a base class with a metaclass. Copied from the six library.
Used like this:
class FormatterABC(with_metaclass(abc.ABCMeta, object)):
...
Combining inheritance between Qt and the traitlets system, however, does not work with this. Instead, we
do this:
class QtKernelClientMixin(MetaQObjectHasTraits('NewBase', (HasTraits,
˓→SuperQObject), {})):
...
This gives the new class a metaclass of MetaQObjectHasTraits, and the parent classes HasTraits
and SuperQObject.
Doctests
IPython.utils.py3compat.doctest_refactor_print(func_or_str)
Refactors print statements in doctests in Python 3 only. Accepts a string or a function, so it can be
used as a decorator.
IPython.utils.py3compat.u_format(func_or_str)
Handle doctests written with {u}'abcþ', replacing the {u} with u for Python 2, and removing it
for Python 3.
Accepts a string or a function, so it can be used as a decorator.
Execfile
Miscellaneous
IPython.utils.py3compat.safe_unicode(e)
unicode(e) with various fallbacks. Used for exceptions, which may not be safe to call unicode() on.
IPython.utils.py3compat.isidentifier(s, dotted=False)
Checks whether the string s is a valid identifier in this version of Python. In Python 3, non-ascii
characters are allowed. If dotted is True, it allows dots (i.e. attribute access) in the string.
IPython.utils.py3compat.getcwd()
Return the current working directory as unicode, like os.getcwdu() on Python 2.
IPython.utils.py3compat.MethodType()
Constructor for types.MethodType that takes two arguments, like the real constructor on Python
3.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
There are a number of abstractions that the IPython configuration system uses. Each of these abstractions is
represented by a Python class.
Configuration object: Config A configuration object is a simple dictionary-like class that holds config-
uration attributes and sub-configuration objects. These classes support dotted attribute style access
(cfg.Foo.bar) in addition to the regular dictionary style access (cfg['Foo']['bar']). The
Config object is a wrapper around a simple dictionary with some convenience methods, such as merg-
ing and automatic section creation.
Application: Application An application is a process that does a specific job. The most obvious ap-
plication is the ipython command line program. Each application reads one or more configuration
files and a single set of command line options and then produces a master configuration object for the
application. This configuration object is then passed to the configurable objects that the application
creates. These configurable objects implement the actual logic of the application and know how to
configure themselves given the configuration object.
Applications always have a log attribute that is a configured Logger. This allows centralized logging
configuration per-application.
Configurable: Configurable A configurable is a regular Python class that serves as a base class for
all main classes in an application. The Configurable base class is lightweight and only does one
things.
This Configurable is a subclass of HasTraits that knows how to configure itself. Class level
traits with the metadata config=True become values that can be configured from the command
line and configuration files.
Developers create Configurable subclasses that implement all of the logic in the application. Each
of these subclasses has its own configuration information that controls how instances are created.
Singletons: SingletonConfigurable Any object for which there is a single canonical instance.
These are just like Configurables, except they have a class method instance(), that returns
the current active instance (or creates one if it does not exist). Examples of singletons include
InteractiveShell. This lets objects easily connect to the current running Application with-
out passing objects around everywhere. For instance, to get the current running Application instance,
simply do: app = Application.instance().
Note: Singletons are not strictly enforced - you can have many instances of a given singleton class, but the
instance() method will always return the same one.
Having described these main concepts, we can now state the main idea in our configuration system: “con-
figuration” allows the default values of class attributes to be controlled on a class by class basis. Thus
all instances of a given class are configured in the same way. Furthermore, if two instances need to be
configured differently, they need to be instances of two different classes. While this model may seem a bit
restrictive, we have found that it expresses most things that need to be configured extremely well. How-
ever, it is possible to create two instances of the same class that have different trait values. This is done by
overriding the configuration.
Now, we show what our configuration objects and files look like.
A configuration object is little more than a wrapper around a dictionary. A configuration file is simply a
mechanism for producing that object. The main IPython configuration file is a plain Python script, which
can perform extensive logic to populate the config object. IPython 2.0 introduces a JSON configuration
file, which is just a direct JSON serialization of the config dictionary, which is easily processed by external
software.
When both Python and JSON configuration file are present, both will be loaded, with JSON configuration
having higher priority.
A Python configuration file is a pure Python file that populates a configuration object. This configuration
object is a Config instance. While in a configuration file, to get a reference to this object, simply call the
get_config() function, which is available in the global namespace of the script.
Here is an example of a super simple configuration file that does nothing:
c = get_config()
Once you get a reference to the configuration object, you simply set attributes on it. All you have to know
is:
• The name of the class to configure.
• The name of the attribute.
• The type of each attribute.
The answers to these questions are provided by the various Configurable subclasses that an application
uses. Let’s look at how this would work for a simple configurable subclass:
# Sample configurable:
from IPython.config.configurable import Configurable
from IPython.utils.traitlets import Int, Float, Unicode, Bool
class MyClass(Configurable):
name = Unicode(u'defaultname', config=True)
ranking = Int(0, config=True)
value = Float(99.0)
# The rest of the class implementation would go here..
In this example, we see that MyClass has three attributes, two of which (name, ranking) can be con-
figured. All of the attributes are given types and default values. If a MyClass is instantiated, but not
configured, these default values will be used. But let’s see how to configure this class in a configuration file:
c.MyClass.name = 'coolname'
c.MyClass.ranking = 10
After this configuration file is loaded, the values set in it will override the class defaults anytime a MyClass
is created. Furthermore, these attributes will be type checked and validated anytime they are set. This type
checking is handled by the IPython.utils.traitlets module, which provides the Unicode, Int
and Float types. In addition to these traitlets, the IPython.utils.traitlets provides traitlets for
a number of other types.
Note: Underneath the hood, the Configurable base class is a subclass of IPython.utils.
traitlets.HasTraits. The IPython.utils.traitlets module is a lightweight version
of enthought.traits. Our implementation is a pure Python subset (mostly API compatible) of
enthought.traits that does not have any of the automatic GUI generation capabilities. Our plan
is to achieve 100% API compatibility to enable the actual enthought.traits to eventually be used
instead. Currently, we cannot use enthought.traits as we are committed to the core of IPython being
pure Python.
It should be very clear at this point what the naming convention is for configuration attributes:
c.ClassName.attribute_name = attribute_value
Here, ClassName is the name of the class whose configuration attribute you want to set,
attribute_name is the name of the attribute you want to set and attribute_value the the value
you want it to have. The ClassName attribute of c is not the actual class, but instead is another Config
instance.
Note: The careful reader may wonder how the ClassName (MyClass in the above example) attribute of
the configuration object c gets created. These attributes are created on the fly by the Config instance, using
a simple naming convention. Any attribute of a Config instance whose name begins with an uppercase
character is assumed to be a sub-configuration and a new empty Config instance is dynamically created
for that attribute. This allows deeply hierarchical information created easily (c.Foo.Bar.value) on the
fly.
A JSON configuration file is simply a file that contains a Config dictionary serialized to JSON. A JSON
configuration file has the same base name as a Python configuration file, but with a .json extension.
Configuration described in previous section could be written as follows in a JSON configuration file:
{
"version": "1.0",
"MyClass": {
"name": "coolname",
"ranking": 10
}
}
JSON configuration files can be more easily generated or processed by programs or other languages.
Let’s say you want to have different configuration files for various purposes. Our configuration sys-
tem makes it easy for one configuration file to inherit the information in another configuration file. The
load_subconfig() command can be used in a configuration file for this purpose. Here is a simple
example that loads all of the values from the file base_config.py:
# base_config.py
c = get_config()
c.MyClass.name = 'coolname'
c.MyClass.ranking = 100
# main_config.py
c = get_config()
In a situation like this the load_subconfig() makes sure that the search path for sub-configuration files
is inherited from that of the parent. Thus, you can typically put the two in the same directory and everything
will just work.
You can also load configuration files by profile, for instance:
load_subconfig('ipython_config.py', profile='default')
There is another aspect of configuration where inheritance comes into play. Sometimes, your classes will
have an inheritance hierarchy that you want to be reflected in the configuration system. Here is a simple
example:
class Foo(Configurable):
name = Unicode(u'fooname', config=True)
value = Float(100.0, config=True)
class Bar(Foo):
name = Unicode(u'barname', config=True)
othervalue = Int(0, config=True)
Now, we can create a configuration file to configure instances of Foo and Bar:
# config file
c = get_config()
c.Foo.name = u'bestname'
c.Bar.othervalue = 10
So where should you put your configuration files? IPython uses “profiles” for configuration, and by default,
all profiles will be stored in the so called “IPython directory”. The location of this directory is determined
by the following algorithm:
• If the ipython-dir command line flag is given, its value is used.
• If not, the value returned by IPython.utils.path.get_ipython_dir() is used. This func-
tion will first look at the IPYTHONDIR environment variable and then default to ~/.ipython.
Historical support for the IPYTHON_DIR environment variable will be removed in a future release.
For most users, the configuration directory will be ~/.ipython.
Previous versions of IPython on Linux would use the XDG config directory, creating ~/.config/
ipython by default. We have decided to go back to ~/.ipython for consistency among systems.
IPython will issue a warning if it finds the XDG location, and will move it to the new location if there
isn’t already a directory there.
Once the location of the IPython directory has been determined, you need to know which profile you
are using. For users with a single configuration, this will simply be ‘default’, and will be located in
<IPYTHONDIR>/profile_default.
The next thing you need to know is what to call your configuration file. The basic idea is that each ap-
plication has its own default configuration filename. The default named used by the ipython command
line program is ipython_config.py, and all IPython applications will use this file. Other applica-
tions, such as the parallel ipcluster scripts or the QtConsole will load their own config files after
ipython_config.py. To load a particular configuration file instead of the default, the name can be
overridden by the config_file command line flag.
To generate the default configuration files, do:
and you will have a default ipython_config.py in your IPython directory under
profile_default. If you want the default config files for the IPython.parallel applica-
tions, add --parallel to the end of the command-line args.
From the command-line, you can quickly locate the IPYTHONDIR or a specific profile with:
$ ipython locate
/home/you/.ipython
Profiles
A profile is a directory containing configuration and runtime files, such as logs, connection info for the
parallel apps, and your IPython command history.
The idea is that users often want to maintain a set of configuration files for different purposes: one for
doing numerical computing with NumPy and SciPy and another for doing symbolic computing with SymPy.
Profiles make it easy to keep a separate configuration files, logs, and histories for each of these purposes.
Let’s start by showing how a profile is used:
$ ipython --profile=sympy
This tells the ipython command line program to get its configuration from the “sympy” profile. The file
names for various profiles do not change. The only difference is that profiles are named in a special way.
In the case above, the “sympy” profile means looking for ipython_config.py in <IPYTHONDIR>/
profile_sympy.
The general pattern is this: simply create a new profile with:
which adds a directory called profile_<name> to your IPython directory. Then you can load this profile
by adding --profile=<name> to your command line options. Profiles are supported by all IPython
applications.
IPython ships with some sample profiles in IPython/config/profile. If you create profiles with
the name of one of our shipped profiles, these config files will be copied over instead of starting with the
automatically generated config files.
Security Files
If you are using the notebook, qtconsole, or parallel code, IPython stores connection information in small
JSON files in the active profile’s security directory. This directory is made private, so only you can see the
files inside. If you need to move connection files around to other computers, this is where they will be. If
you want your code to be able to open security files by name, we have a convenience function IPython.
utils.path.get_security_file(), which will return the absolute path to a security file from its
filename and [optionally] profile name.
Startup Files
If you want some code to be run at the beginning of every IPython session with a particular profile, the
easiest way is to add Python (.py) or IPython (.ipy) scripts to your <profile>/startup directory.
Files in this directory will always be executed as soon as the IPython shell is constructed, and before any
other code or scripts you have specified. If you have multiple files in the startup directory, they will be run
in lexicographical order, so you can control the ordering by adding a ‘00-‘ prefix.
Command-line arguments
IPython exposes all configurable options on the command-line. The command-line arguments are generated
from the Configurable traits of the classes associated with a given Application. Configuring IPython from
the command-line may look very similar to an IPython config file
IPython applications use a parser called KeyValueLoader to load values into a Config object. Values are
assigned in much the same way as in a config file:
c.InteractiveShell.use_readline=False
c.BaseIPythonApplication.profile='myprofile'
to your config file. Key/Value arguments always take a value, separated by ‘=’ and no spaces.
Common Arguments
Since the strictness and verbosity of the KVLoader above are not ideal for everyday use, common arguments
can be specified as flags or aliases.
Flags and Aliases are handled by argparse instead, allowing for more flexible parsing. In general, flags
and aliases are prefixed by --, except for those that are single characters, in which case they can be specified
with a single -, e.g.:
Aliases
For convenience, applications have a mapping of commonly used traits, so you don’t have to specify the
whole class name:
Flags
Applications can also be passed flags. Flags are options that take no arguments. They are simply wrappers
for setting one or more configurables with predefined values, often True/False.
For instance:
$ ipcontroller --debug
# is equivalent to
$ ipcontroller --Application.log_level=DEBUG
# and
$ ipython --matplotlib
# is equivalent to
$ ipython --matplotlib auto
# or
$ ipython --no-banner
# is equivalent to
$ ipython --TerminalIPythonApp.display_banner=False
Subcommands
Some IPython applications have subcommands. Subcommands are modeled after git, and are called with
the form command subcommand [...args]. Currently, the QtConsole is a subcommand of terminal
IPython:
and ipcluster is simply a wrapper for its various subcommands (start, stop, engines).
To see a list of the available aliases, flags, and subcommands for an IPython application, simply pass -h or
--help. And to see the full list of configurable options (very long), pass --help-all.
Design requirements
Here are the main requirements we wanted our configuration system to have:
• Support for hierarchical configuration information.
• Full integration with command line option parsers. Often, you want to read a configuration file, but
then override some of the values with command line options. Our configuration system automates this
process and allows each command line option to be linked to a particular attribute in the configuration
hierarchy that it will override.
• Configuration files that are themselves valid Python code. This accomplishes many things. First, it
becomes possible to put logic in your configuration files that sets attributes based on your operating
system, network setup, Python version, etc. Second, Python has a super simple syntax for accessing
hierarchical data structures, namely regular attribute access (Foo.Bar.Bam.name). Third, using
Python makes it easy for users to import configuration attributes from one configuration file to another.
Fourth, even though Python is dynamically typed, it does have types that can be checked at runtime.
Thus, a 1 in a config file is the integer ‘1’, while a '1' is a string.
• A fully automated method for getting the configuration information to the classes that need it at
runtime. Writing code that walks a configuration hierarchy to extract a particular attribute is painful.
When you have complex configuration information with hundreds of attributes, this makes you want
to cry.
• Type checking and validation that doesn’t require the entire configuration hierarchy to be specified
statically before runtime. Python is a very dynamic language and you don’t always know everything
that needs to be configured when a program starts.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
IPython allows GUI event loops to be run in an interactive IPython session. This is done using Python’s
PyOS_InputHook hook which Python calls when the raw_input() function is called and waiting for
user input. IPython has versions of this hook for wx, pyqt4 and pygtk.
When a GUI program is used interactively within IPython, the event loop of the GUI should not be started.
This is because, the PyOS_Inputhook itself is responsible for iterating the GUI event loop.
IPython has facilities for installing the needed input hook for each GUI toolkit and for creating the needed
main GUI application object. Usually, these main application objects should be created only once and
for some GUI toolkits, special options have to be passed to the application object to enable it to function
properly in IPython.
We need to answer the following questions:
• Who is responsible for creating the main GUI application object, IPython or third parties (matplotlib,
enthought.traits, etc.)?
• What is the proper way for third party code to detect if a GUI application object has already been
created? If one has been created, how should the existing instance be retrieved?
• In a GUI application object has been created, how should third party code detect if the GUI event
loop is running. It is not sufficient to call the relevant function methods in the GUI toolkits (like
IsMainLoopRunning) because those don’t know if the GUI event loop is running through the
input hook.
• We might need a way for third party code to determine if it is running in IPython or not. Currently,
the only way of running GUI code in IPython is by using the input hook, but eventually, GUI based
versions of IPython will allow the GUI event loop in the more traditional manner. We will need a way
for third party code to distinguish between these two cases.
Here is some sample code I have been using to debug this issue:
class Foo(traits.HasTraits):
a = traits.Float()
f = Foo()
f.configure_traits()
plt.plot(range(10))
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
499
IPython Documentation, Release 3.0.0-dev
About IPython
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Credits
Core developers
501
IPython Documentation, Release 3.0.0-dev
Special thanks
Sponsors
We would like to thank the following entities which, at one point or another, have provided resources and
support to IPython:
• Enthought (http://www.enthought.com), for hosting IPython’s website and supporting the project in
various ways over the years, including significant funding and resources in 2010 for the development
of our modern ZeroMQ-based architecture and Qt console frontend.
• Google, for supporting IPython through Summer of Code sponsorships in 2005 and 2010.
• Microsoft Corporation, for funding in 2009 the development of documentation and examples of the
Windows HPC Server 2008 support in IPython’s parallel computing tools.
• The Nipy project (http://nipy.org) for funding in 2009 a significant refactoring of the entire project
codebase that was key.
• Ohio Supercomputer Center ( part of Ohio State University Research Foundation) and the Department
of Defense High Performance Computing Modernization Program (HPCMP), for sponsoring work in
2009 on the ipcluster script used for starting IPython’s parallel computing processes, as well as the in-
tegration between IPython and the Vision environment (http://mgltools.scripps.edu/packages/vision).
This project would not have been possible without the support and leadership of Jose Unpingco, from
Ohio State.
• Tech-X Corporation, for sponsoring a NASA SBIR project in 2008 on IPython’s distributed array and
parallel computing capabilities.
• Bivio Software (http://www.bivio.biz/bp/Intro), for hosting an IPython sprint in 2006 in addition to
their support of the Front Range Pythoneers group in Boulder, CO.
Contributors
And last but not least, all the kind IPython contributors who have contributed new code, bug reports, fixes,
comments and ideas. A brief list follows, please let us know if we have omitted your name by accident:
• Mark Voorhies <mark.voorhies-AT-ucsf.edu> Printing support in Qt console.
• Justin Riley <justin.t.riley-AT-gmail.com> Contributions to parallel support, Amazon EC2, Sun Grid
Engine, documentation.
• Satrajit Ghosh <satra-AT-mit.edu> parallel computing (SGE and much more).
• Thomas Spura <tomspur-AT-fedoraproject.org> various fixes motivated by Fedora support.
• Omar Andrés Zapata Mesa <andresete.chaos-AT-gmail.com> Google Summer of Code 2010, terminal
support with ZeroMQ
• Gerardo Gutierrez <muzgash-AT-gmail.com> Google Summer of Code 2010, Qt notebook frontend
support with ZeroMQ.
• Paul Ivanov <pivanov314-AT-gmail.com> multiline specials improvements.
• Dav Clark <davclark-AT-berkeley.edu> traitlets improvements.
• David Warde-Farley <wardefar-AT-iro.umontreal.ca> - bugfixes to %timeit, input autoindent manage-
ment, and Qt console tooltips.
• Darren Dale <dsdale24-AT-gmail.com>, traits-based configuration system, Qt support.
• Jose Unpingco <[email protected]> authored multiple tutorials and screencasts teaching the use
of IPython both for interactive and parallel work (available in the documentation part of our website).
• Dan Milstein <danmil-AT-comcast.net> A bold refactor of the core prefilter machinery in the IPython
interpreter.
• Jack Moffit <jack-AT-xiph.org> Bug fixes, including the infamous color problem. This bug alone
caused many lost hours and frustration, many thanks to him for the fix. I’ve always been a fan of
Ogg & friends, now I have one more reason to like these folks. Jack is also contributing with Debian
packaging and many other things.
• Alexander Schmolck <a.schmolck-AT-gmx.net> Emacs work, bug reports, bug fixes, ideas, lots more.
The ipython.el mode for (X)Emacs is Alex’s code, providing full support for IPython under (X)Emacs.
• Andrea Riciputi <andrea.riciputi-AT-libero.it> Mac OSX information, Fink package management.
• Gary Bishop <gb-AT-cs.unc.edu> Bug reports, and patches to work around the exception handling
idiosyncracies of WxPython. Readline and color support for Windows.
• Jeffrey Collins <Jeff.Collins-AT-vexcel.com>. Bug reports. Much improved readline support, includ-
ing fixes for Python 2.3.
• Dryice Liu <dryice-AT-liu.com.cn> FreeBSD port.
• Mike Heeter <korora-AT-SDF.LONESTAR.ORG>
• Christopher Hart <hart-AT-caltech.edu> PDB integration.
• Milan Zamazal <pdm-AT-zamazal.org> Emacs info.
• Philip Hisley <compsys-AT-starpower.net>
• Holger Krekel <pyth-AT-devel.trillke.net> Tab completion, lots more.
• Robin Siebler <robinsiebler-AT-starband.net>
• Ralf Ahlbrink <ralf_ahlbrink-AT-web.de>
• Thorsten Kampe <thorsten-AT-thorstenkampe.de>
• Fredrik Kant <fredrik.kant-AT-front.com> Windows setup.
• Syver Enstad <syver-en-AT-online.no> Windows setup.
• Richard <rxe-AT-renre-europe.com> Global embedding.
• Hayden Callow <h.callow-AT-elec.canterbury.ac.nz> Gnuplot.py 1.6 compatibility.
• Leonardo Santagada <retype-AT-terra.com.br> Fixes for Windows installation.
• Christopher Armstrong <radix-AT-twistedmatrix.com> Bugfixes.
• Francois Pinard <pinard-AT-iro.umontreal.ca> Code and documentation fixes.
• Cory Dodt <cdodt-AT-fcoe.k12.ca.us> Bug reports and Windows ideas. Patches for Windows in-
staller.
• Olivier Aubert <oaubert-AT-bat710.univ-lyon1.fr> New magics.
• King C. Shu <kingshu-AT-myrealbox.com> Autoindent patch.
• Chris Drexler <chris-AT-ac-drexler.de> Readline packages for Win32/CygWin.
• Gustavo Cordova Avila <gcordova-AT-sismex.com> EvalDict code for nice, lightweight string inter-
polation.
• Kasper Souren <Kasper.Souren-AT-ircam.fr> Bug reports, ideas.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
History
Origins
IPython was starting in 2001 by Fernando Perez while he was a graduate student at the University of Col-
orado, Boulder. IPython as we know it today grew out of the following three projects:
• ipython by Fernando Pérez. Fernando began using Python and ipython began as an outgrowth of his
desire for things like Mathematica-style prompts, access to previous output (again like Mathematica’s
% syntax) and a flexible configuration system (something better than PYTHONSTARTUP).
• IPP by Janko Hauser. Very well organized, great usability. Had an old help system. IPP was used as
the “container” code into which Fernando added the functionality from ipython and LazyPython.
• LazyPython by Nathan Gray. Simple but very powerful. The quick syntax (auto parens, auto quotes)
and verbose/colored tracebacks were all taken from here.
Here is how Fernando describes the early history of IPython:
When I found out about IPP and LazyPython I tried to join all three into a unified system. I
thought this could provide a very nice working environment, both for regular programming
and scientific computing: shell-like features, IDL/Matlab numerics, Mathematica-type prompt
history and great object introspection and help facilities. I think it worked reasonably well,
though it was a lot more work than I had initially planned.
Note: This documentation is for a development version of IPython. There may be significant
differences from the latest stable release.
Licenses
IPython source code and examples are licensed under the terms of the new or revised BSD license, as
follows:
Neither the name of the IPython Development Team nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
IPython documentation, examples and other materials are licensed under the terms of the Attribution 4.0
International (CC BY 4.0) license, as follows:
Creative Commons Attribution 4.0 International Public License
By exercising the Licensed Rights (defined below), You accept and agree
to be bound by the terms and conditions of this Creative Commons
Attribution 4.0 International Public License ("Public License"). To the
extent this Public License may be interpreted as a contract, You are
granted the Licensed Rights in consideration of Your acceptance of
these terms and conditions, and the Licensor grants You such rights in
consideration of benefits the Licensor receives from making the
Licensed Material available under these terms and conditions.
Section 1 -- Definitions.
Section 2 -- Scope.
a. License grant.
5. Downstream recipients.
b. Other rights.
a. Attribution.
Where the Licensed Rights include Sui Generis Database Rights that
apply to Your use of the Licensed Material:
a. for the avoidance of doubt, Section 2(a)(1) grants You the right
to extract, reuse, reproduce, and Share all or a substantial
portion of the contents of the database;
c. You must comply with the conditions in Section 3(a) if You Share
all or a substantial portion of the contents of the database.
For the avoidance of doubt, this Section 4 supplements and does not
replace Your obligations under this Public License where the Licensed
Rights include other Copyright and Similar Rights.
a. This Public License applies for the term of the Copyright and
Similar Rights licensed here. However, if You fail to comply with
this Public License, then Your rights under this Public License
terminate automatically.
b. Where Your right to use the Licensed Material has terminated under
Section 6(a), it reinstates:
For the avoidance of doubt, this Section 6(b) does not affect any
right the Licensor may have to seek remedies for Your violations
of this Public License.
c. For the avoidance of doubt, the Licensor may also offer the
Licensed Material under separate terms or conditions or stop
distributing the Licensed Material at any time; however, doing so
will not terminate this Public License.
Section 8 -- Interpretation.
a. For the avoidance of doubt, this Public License does not, and
shall not be interpreted to, reduce, limit, restrict, or impose
conditions on any use of the Licensed Material that could lawfully
be made without permission under this Public License.
Fernando Perez began IPython in 2001 based on code from Janko Hauser <jhauser-AT-zscout.de> and
Nathaniel Gray <n8gray-AT-caltech.edu>. Fernando is still the project lead.
The IPython Development Team is the set of all contributors to the IPython project. This includes all of the
IPython subprojects. Here is a list of the currently active contributors:
• Matthieu Brucher
• Ondrej Certik
• Laurent Dufrechou
• Robert Kern
• Thomas Kluyver
• Brian E. Granger
• Paul Ivanov
• Evan Patterson
• Fernando Perez (project leader)
• Benjamin Ragan-Kelley
• Ville M. Vainio
• Gael Varoququx
• Stefan van der Walt
• Barry Wark
IPython uses a shared copyright model. Each contributor maintains copyright over their contributions to
IPython. But, it is important to note that these contributions are typically only changes (diffs/commits) to
the repositories. Thus, the IPython source code, in its entirety is not the copyright of any single person or
institution. Instead, it is the collective copyright of the entire IPython Development Team. If individual
contributors want to maintain a record of what changes/contributions they have specific copyright on, they
should indicate their copyright in the commit message of the change, when they commit the change to one
of the IPython repositories.
Any new code contributed to IPython must be licensed under the BSD license or a similar (MIT) open source
license.
Miscellaneous
Some files (DPyGetOpt.py, for example) may be licensed under different conditions. Ultimately each file
indicates clearly the conditions under which its author/authors have decided to publish the code.
Versions of IPython up to and including 0.6.3 were released under the GNU Lesser General Public License
(LGPL), available at http://www.gnu.org/copyleft/lesser.html.
Online versions of the Creative Commons licenses can be found at:
• http://creativecommons.org/licenses/by/4.0/
• http://creativecommons.org/licenses/by/4.0/legalcode.txt
515
IPython Documentation, Release 3.0.0-dev
516 Bibliography
Python Module Index
e
IPython.extensions.autoreload, 423
IPython.extensions.storemagic, 425
IPython.extensions.sympyprinting,
426
u
IPython.utils.py3compat, 483
517
IPython Documentation, Release 3.0.0-dev
C G
cast_bytes() (in module IPython.utils.py3compat), get() (AsyncResult method), 405
485 getcwd() (in module IPython.utils.py3compat), 487
cast_bytes_py2() (in module
IPython.utils.py3compat), 485
H
cast_unicode() (in module IPython.utils.py3compat), HOME, 262
485
cast_unicode_py2() (in module
I
IPython.utils.py3compat), 485 implementation (MyKernel attribute), 465
command line option implementation_version (MyKernel attribute), 465
–ipython-dir=<path>, 417 input() (in module IPython.utils.py3compat), 485
INPUTRC, 266
D IPython.extensions.autoreload (module), 423
do_complete() (MyKernel method), 466 IPython.extensions.storemagic (module), 425
do_execute() (MyKernel method), 465 IPython.extensions.sympyprinting (module), 426
do_history() (MyKernel method), 467 IPython.utils.py3compat (module), 483
do_inspect() (MyKernel method), 467 IPYTHON_DIR, 141, 492
do_is_complete() (MyKernel method), 467 IPYTHONDIR, 141, 262, 492
519
IPython Documentation, Release 3.0.0-dev
L
language (MyKernel attribute), 465
language_info (MyKernel attribute), 465
language_version (MyKernel attribute), 465
M
MethodType() (in module IPython.utils.py3compat),
487
MyKernel (built-in class), 465, 466
P
PATH, 4
PY3 (in module IPython.utils.py3compat), 483
PYTHONSTARTUP, 272, 506
R
ready() (AsyncResult method), 405
S
safe_unicode() (in module
IPython.utils.py3compat), 487
stdin_ready() (in module IPython.lib.inputhook),
434
store() (IPython.extensions.storemagic.StoreMagics
method), 425
str_to_bytes() (in module IPython.utils.py3compat),
485
str_to_unicode() (in module
IPython.utils.py3compat), 485
string_types (in module IPython.utils.py3compat),
486
successful() (AsyncResult method), 405
U
u_format() (in module IPython.utils.py3compat),
487
unicode_to_str() (in module
IPython.utils.py3compat), 485
unicode_type (in module IPython.utils.py3compat),
486
W
wait() (AsyncResult method), 405
520 Index