overview.txt
234 lines
| 10.1 KiB
| text/plain
|
TextLexer
Brian E Granger
|
r1258 | .. _overview: | ||
============ | ||||
Introduction | ||||
============ | ||||
Overview | ||||
======== | ||||
One of Python's most useful features is its interactive interpreter. | ||||
This system allows 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. | ||||
Brian E Granger
|
r1400 | The goal of IPython is to create a comprehensive environment for | ||
Brian Granger
|
r1716 | interactive and exploratory computing. To support this goal, IPython | ||
Brian E Granger
|
r1400 | has two main components: | ||
Brian Granger
|
r1677 | * An enhanced interactive Python shell. | ||
* An architecture for interactive parallel computing. | ||||
Brian E Granger
|
r1400 | |||
All of IPython is open source (released under the revised BSD license). | ||||
Enhanced interactive Python shell | ||||
================================= | ||||
Brian Granger
|
r1677 | IPython's interactive shell (:command:`ipython`), has the following goals, | ||
amongst others: | ||||
1. Provide an interactive shell superior to Python's default. IPython | ||||
has many features for object introspection, system shell access, | ||||
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. IPython can be started with a single call from inside | ||||
another program, providing access to the current namespace. This | ||||
can be very useful both for debugging purposes and for situations | ||||
where a blend of batch-processing and interactive exploration are | ||||
needed. New in the 0.9 version of IPython is a reusable wxPython | ||||
based IPython widget. | ||||
3. Offer a flexible framework which can be used as the base | ||||
environment for other systems with Python as the underlying | ||||
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 and | ||||
WX applications via special threading flags. The normal Python | ||||
shell can only do this for Tkinter applications. | ||||
Brian E Granger
|
r1258 | |||
Brian E Granger
|
r1400 | Main features of the interactive shell | ||
-------------------------------------- | ||||
Brian Granger
|
r1677 | * 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 (:samp:`?`, and using :samp:`??` provides additional detail). | ||||
* Searching through modules and namespaces with :samp:`*` wildcards, both | ||||
when using the :samp:`?` system and via the :samp:`%psearch` command. | ||||
* Completion in the local namespace, by typing :kbd:`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 | ||||
:samp:`%` 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 :samp:`!` are passed | ||||
directly to the system shell, and using :samp:`!!` or :samp:`var = !cmd` | ||||
captures shell output into python variables for further use. | ||||
* Background execution of Python commands in a separate thread. | ||||
IPython has an internal job manager called jobs, and a | ||||
convenience backgrounding magic function called :samp:`%bg`. | ||||
Fernando Perez
|
r1753 | * The ability to expand python variables when calling the system shell. In a | ||
shell command, any python variable prefixed with :samp:`$` is expanded. A | ||||
double :samp:`$$` allows passing a literal :samp:`$` to the shell (for access | ||||
to shell and environment variables like :envvar:`PATH`). | ||||
Brian Granger
|
r1677 | |||
* Filesystem navigation, via a magic :samp:`%cd` command, along with a | ||||
persistent bookmark system (using :samp:`%bookmark`) for fast access to | ||||
frequently visited directories. | ||||
* A lightweight persistence framework via the :samp:`%store` command, which | ||||
allows you to save arbitrary Python variables. These get restored | ||||
automatically when your session restarts. | ||||
* 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. Macros can be stored persistently via | ||||
:samp:`%store` and edited via :samp:`%edit`. | ||||
* 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: callable objects can be executed without | ||||
parentheses: :samp:`sin 3` is automatically converted to :samp:`sin(3)`. | ||||
* Auto-quoting: using :samp:`,`, or :samp:`;` as the first character forces | ||||
auto-quoting of the rest of the line: :samp:`,my_function a b` becomes | ||||
automatically :samp:`my_function("a","b")`, while :samp:`;my_function a b` | ||||
becomes :samp:`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 | ||||
:samp:`>>>` or :samp:`...` 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). | ||||
Fernando Perez
|
r1753 | * 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 :samp:`%run` magic command (with the :samp:`-d` option) can run | ||||
any script under pdb's control, automatically setting initial breakpoints for | ||||
you. This version of pdb has IPython-specific improvements, including | ||||
tab-completion and traceback coloring support. For even easier debugger | ||||
access, try :samp:`%debug` after seeing an exception. winpdb is also | ||||
supported, see ipy_winpdb extension. | ||||
Brian Granger
|
r1677 | |||
* Profiler support. You can run single statements (similar to | ||||
:samp:`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 :samp:`%prun` | ||||
and :samp:`%run -p`) convenient for rapid interactive work. | ||||
* Doctest support. The special :samp:`%doctest_mode` command toggles a mode | ||||
that allows you to paste existing doctests (with leading :samp:`>>>` | ||||
prompts and whitespace) and uses doctest-compatible prompts and | ||||
output, so you can use IPython sessions as doctest code. | ||||
Brian E Granger
|
r1400 | |||
Interactive parallel computing | ||||
============================== | ||||
Fernando Perez
|
r1753 | Increasingly, parallel computer hardware, such as multicore CPUs, clusters and | ||
supercomputers, is becoming ubiquitous. Over the last 3 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. | ||||
Brian E Granger
|
r1400 | |||
Brian Granger
|
r1677 | 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 farming. And all of these styles can be handled | ||||
interactively. | ||||
* Both blocking and fully asynchronous interfaces. | ||||
* High level APIs that enable many things to be parallelized in a few lines | ||||
of code. | ||||
* Write parallel code that will run unchanged on everything from multicore | ||||
workstations to supercomputers. | ||||
* Full integration with Message Passing libraries (MPI). | ||||
* Capabilities based security model with full encryption of network connections. | ||||
Fernando Perez
|
r1753 | * Share live parallel jobs with other users securely. We call this | ||
collaborative parallel computing. | ||||
Brian Granger
|
r1677 | |||
* Dynamically load balanced task farming system. | ||||
* Robust error handling. Python exceptions raised in parallel execution are | ||||
gathered and presented to the top-level code. | ||||
Fernando Perez
|
r1753 | For more information, see our :ref:`overview <parallel_index>` of using IPython | ||
for parallel computing. | ||||
Brian E Granger
|
r1258 | |||
Portability and Python requirements | ||||
----------------------------------- | ||||
Brian Granger
|
r2275 | As of the 0.11 release, IPython works with either Python 2.5 or 2.6. | ||
Brian Granger
|
r2276 | Versions 0.9 and 0.10 worked with Python 2.4 as well. We have not yet begun | ||
to test and port IPython to Python 3. Our plan is to gradually drop Python 2.5 | ||||
support and then begin the transition to strict 2.6 and 3. | ||||
Brian E Granger
|
r1400 | |||
IPython is known to work on the following operating systems: | ||||
* Linux | ||||
Fernando Perez
|
r1753 | * Most other Unix-like OSs (AIX, Solaris, BSD, etc.) | ||
Brian E Granger
|
r1400 | * Mac OS X | ||
* Windows (CygWin, XP, Vista, etc.) | ||||
Brian Granger
|
r2275 | See :ref:`here <install_index>` for instructions on how to install IPython. | ||