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