##// END OF EJS Templates
updating overview to include two-process model
Paul Ivanov -
Show More
@@ -1,235 +1,269
1 1 .. _overview:
2 2
3 3 ============
4 4 Introduction
5 5 ============
6 6
7 7 Overview
8 8 ========
9 9
10 10 One of Python's most useful features is its interactive interpreter.
11 11 This system allows very fast testing of ideas without the overhead of
12 12 creating test files as is typical in most programming languages.
13 13 However, the interpreter supplied with the standard Python distribution
14 14 is somewhat limited for extended interactive use.
15 15
16 16 The goal of IPython is to create a comprehensive environment for
17 17 interactive and exploratory computing. To support this goal, IPython
18 has two main components:
18 has three main components:
19 19
20 20 * An enhanced interactive Python shell.
21 * A decoupled two-process communication model, which allows for multiple
22 clients to connect to a computation kernel, most notably the web-based
23 :ref:`notebook <htmlnotebook>`
21 24 * An architecture for interactive parallel computing.
22 25
23 26 All of IPython is open source (released under the revised BSD license).
24 27
25 28 Enhanced interactive Python shell
26 29 =================================
27 30
28 31 IPython's interactive shell (:command:`ipython`), has the following goals,
29 32 amongst others:
30 33
31 34 1. Provide an interactive shell superior to Python's default. IPython
32 35 has many features for object introspection, system shell access,
33 36 and its own special command system for adding functionality when
34 37 working interactively. It tries to be a very efficient environment
35 38 both for Python code development and for exploration of problems
36 39 using Python objects (in situations like data analysis).
37 40
38 41 2. Serve as an embeddable, ready to use interpreter for your own
39 42 programs. IPython can be started with a single call from inside
40 43 another program, providing access to the current namespace. This
41 44 can be very useful both for debugging purposes and for situations
42 45 where a blend of batch-processing and interactive exploration are
43 46 needed. New in the 0.9 version of IPython is a reusable wxPython
44 47 based IPython widget.
45 48
46 49 3. Offer a flexible framework which can be used as the base
47 50 environment for other systems with Python as the underlying
48 51 language. Specifically scientific environments like Mathematica,
49 52 IDL and Matlab inspired its design, but similar ideas can be
50 53 useful in many fields.
51 54
52 55 4. Allow interactive testing of threaded graphical toolkits. IPython
53 56 has support for interactive, non-blocking control of GTK, Qt and
54 57 WX applications via special threading flags. The normal Python
55 58 shell can only do this for Tkinter applications.
56 59
57 60 Main features of the interactive shell
58 61 --------------------------------------
59 62
60 63 * Dynamic object introspection. One can access docstrings, function
61 64 definition prototypes, source code, source files and other details
62 65 of any object accessible to the interpreter with a single
63 66 keystroke (:samp:`?`, and using :samp:`??` provides additional detail).
64 67
65 68 * Searching through modules and namespaces with :samp:`*` wildcards, both
66 69 when using the :samp:`?` system and via the :samp:`%psearch` command.
67 70
68 71 * Completion in the local namespace, by typing :kbd:`TAB` at the prompt.
69 72 This works for keywords, modules, methods, variables and files in the
70 73 current directory. This is supported via the readline library, and
71 74 full access to configuring readline's behavior is provided.
72 75 Custom completers can be implemented easily for different purposes
73 76 (system commands, magic arguments etc.)
74 77
75 78 * Numbered input/output prompts with command history (persistent
76 79 across sessions and tied to each profile), full searching in this
77 80 history and caching of all input and output.
78 81
79 82 * User-extensible 'magic' commands. A set of commands prefixed with
80 83 :samp:`%` is available for controlling IPython itself and provides
81 84 directory control, namespace information and many aliases to
82 85 common system shell commands.
83 86
84 87 * Alias facility for defining your own system aliases.
85 88
86 89 * Complete system shell access. Lines starting with :samp:`!` are passed
87 90 directly to the system shell, and using :samp:`!!` or :samp:`var = !cmd`
88 91 captures shell output into python variables for further use.
89 92
90 93 * Background execution of Python commands in a separate thread.
91 94 IPython has an internal job manager called jobs, and a
92 95 convenience backgrounding magic function called :samp:`%bg`.
93 96
94 97 * The ability to expand python variables when calling the system shell. In a
95 98 shell command, any python variable prefixed with :samp:`$` is expanded. A
96 99 double :samp:`$$` allows passing a literal :samp:`$` to the shell (for access
97 100 to shell and environment variables like :envvar:`PATH`).
98 101
99 102 * Filesystem navigation, via a magic :samp:`%cd` command, along with a
100 103 persistent bookmark system (using :samp:`%bookmark`) for fast access to
101 104 frequently visited directories.
102 105
103 106 * A lightweight persistence framework via the :samp:`%store` command, which
104 107 allows you to save arbitrary Python variables. These get restored
105 108 automatically when your session restarts.
106 109
107 110 * Automatic indentation (optional) of code as you type (through the
108 111 readline library).
109 112
110 113 * Macro system for quickly re-executing multiple lines of previous
111 114 input with a single name. Macros can be stored persistently via
112 115 :samp:`%store` and edited via :samp:`%edit`.
113 116
114 117 * Session logging (you can then later use these logs as code in your
115 118 programs). Logs can optionally timestamp all input, and also store
116 119 session output (marked as comments, so the log remains valid
117 120 Python source code).
118 121
119 122 * Session restoring: logs can be replayed to restore a previous
120 123 session to the state where you left it.
121 124
122 125 * Verbose and colored exception traceback printouts. Easier to parse
123 126 visually, and in verbose mode they produce a lot of useful
124 127 debugging information (basically a terminal version of the cgitb
125 128 module).
126 129
127 130 * Auto-parentheses: callable objects can be executed without
128 131 parentheses: :samp:`sin 3` is automatically converted to :samp:`sin(3)`.
129 132
130 133 * Auto-quoting: using :samp:`,`, or :samp:`;` as the first character forces
131 134 auto-quoting of the rest of the line: :samp:`,my_function a b` becomes
132 135 automatically :samp:`my_function("a","b")`, while :samp:`;my_function a b`
133 136 becomes :samp:`my_function("a b")`.
134 137
135 138 * Extensible input syntax. You can define filters that pre-process
136 139 user input to simplify input in special situations. This allows
137 140 for example pasting multi-line code fragments which start with
138 141 :samp:`>>>` or :samp:`...` such as those from other python sessions or the
139 142 standard Python documentation.
140 143
141 144 * Flexible configuration system. It uses a configuration file which
142 145 allows permanent setting of all command-line options, module
143 146 loading, code and file execution. The system allows recursive file
144 147 inclusion, so you can have a base file with defaults and layers
145 148 which load other customizations for particular projects.
146 149
147 150 * Embeddable. You can call IPython as a python shell inside your own
148 151 python programs. This can be used both for debugging code or for
149 152 providing interactive abilities to your programs with knowledge
150 153 about the local namespaces (very useful in debugging and data
151 154 analysis situations).
152 155
153 156 * Easy debugger access. You can set IPython to call up an enhanced version of
154 157 the Python debugger (pdb) every time there is an uncaught exception. This
155 158 drops you inside the code which triggered the exception with all the data
156 159 live and it is possible to navigate the stack to rapidly isolate the source
157 160 of a bug. The :samp:`%run` magic command (with the :samp:`-d` option) can run
158 161 any script under pdb's control, automatically setting initial breakpoints for
159 162 you. This version of pdb has IPython-specific improvements, including
160 163 tab-completion and traceback coloring support. For even easier debugger
161 164 access, try :samp:`%debug` after seeing an exception. winpdb is also
162 165 supported, see ipy_winpdb extension.
163 166
164 167 * Profiler support. You can run single statements (similar to
165 168 :samp:`profile.run()`) or complete programs under the profiler's control.
166 169 While this is possible with standard cProfile or profile modules,
167 170 IPython wraps this functionality with magic commands (see :samp:`%prun`
168 171 and :samp:`%run -p`) convenient for rapid interactive work.
169 172
170 173 * Doctest support. The special :samp:`%doctest_mode` command toggles a mode
171 174 that allows you to paste existing doctests (with leading :samp:`>>>`
172 175 prompts and whitespace) and uses doctest-compatible prompts and
173 176 output, so you can use IPython sessions as doctest code.
174 177
178 Decoupled two-process model
179 ==============================
180
181 IPython has abstracted and extended the notion of a traditional
182 *Read-Evaluate-Print Loop* (REPL) environment by decoupling the *evaluation*
183 into its own process. We call this process a kernel: it receives execution
184 instructions from clients and communicates the results back to them.
185
186 This decoupling allows us to have several clients connected to the same
187 kernel, and even allows clients and kernels to live on different machines.
188 With the exclusion of the traditional single process terminal-based IPython
189 (what you start if you run ``ipython`` without any subcommands), all
190 other IPython machinery uses this two-process model. This includes ``ipython
191 console``, ``ipython qtconsole``, and ``ipython notebook``.
192
193 As an example, this means that when you start ``ipython qtconsole``, you're
194 really starting two processes, a kernel and a Qt-based client can send
195 commands to and receive results from that kernel. If there is already a kernel
196 running that you want to connect to, you can pass the ``--existing`` flag
197 which will skip initiating a new kernel and connect to the most recent kernel,
198 instead. To connect to a specific kernel once you have several kernels
199 running, use the ``%connect_info`` magic to get the unique connection file,
200 which will be something like ``--existing kernel-19732.json`` but with
201 different numbers which correspond to the Process ID of the kernel.
202
203 You can read more about using :ref:`ipython qtconsole <qtconsole>`, and
204 :ref:`ipython notebook <htmlnotebook>`. There is also a :ref:`message spec
205 <messaging>` which documents the protocol for communication between kernels
206 and clients.
207
208
175 209 Interactive parallel computing
176 210 ==============================
177 211
178 212 Increasingly, parallel computer hardware, such as multicore CPUs, clusters and
179 supercomputers, is becoming ubiquitous. Over the last 3 years, we have
213 supercomputers, is becoming ubiquitous. Over the last 8 years, we have
180 214 developed an architecture within IPython that allows such hardware to be used
181 215 quickly and easily from Python. Moreover, this architecture is designed to
182 216 support interactive and collaborative parallel computing.
183 217
184 218 The main features of this system are:
185 219
186 220 * Quickly parallelize Python code from an interactive Python/IPython session.
187 221
188 222 * A flexible and dynamic process model that be deployed on anything from
189 223 multicore workstations to supercomputers.
190 224
191 225 * An architecture that supports many different styles of parallelism, from
192 226 message passing to task farming. And all of these styles can be handled
193 227 interactively.
194 228
195 229 * Both blocking and fully asynchronous interfaces.
196 230
197 231 * High level APIs that enable many things to be parallelized in a few lines
198 232 of code.
199 233
200 234 * Write parallel code that will run unchanged on everything from multicore
201 235 workstations to supercomputers.
202 236
203 237 * Full integration with Message Passing libraries (MPI).
204 238
205 239 * Capabilities based security model with full encryption of network connections.
206 240
207 241 * Share live parallel jobs with other users securely. We call this
208 242 collaborative parallel computing.
209 243
210 244 * Dynamically load balanced task farming system.
211 245
212 246 * Robust error handling. Python exceptions raised in parallel execution are
213 247 gathered and presented to the top-level code.
214 248
215 249 For more information, see our :ref:`overview <parallel_index>` of using IPython
216 250 for parallel computing.
217 251
218 252 Portability and Python requirements
219 253 -----------------------------------
220 254
221 255 As of the 0.11 release, IPython works with Python 2.6 and 2.7. Versions 0.9 and
222 256 0.10 worked with Python 2.4 and above. IPython now also supports Python 3,
223 257 although for now the code for this is separate, and kept up to date with the
224 258 main IPython repository. In the future, these will converge to a single codebase
225 259 which can be automatically translated using 2to3.
226 260
227 261 IPython is known to work on the following operating systems:
228 262
229 263 * Linux
230 264 * Most other Unix-like OSs (AIX, Solaris, BSD, etc.)
231 265 * Mac OS X
232 266 * Windows (CygWin, XP, Vista, etc.)
233 267
234 268 See :ref:`here <install_index>` for instructions on how to install IPython.
235 269
General Comments 0
You need to be logged in to leave comments. Login now