##// END OF EJS Templates
Mention changes to exit and quit in what's new docs.
Thomas Kluyver -
Show More
@@ -1,387 +1,391 b''
1 1 ===============
2 2 0.11 Series
3 3 ===============
4 4
5 5 Release 0.11
6 6 ============
7 7
8 8 IPython 0.11 is a *major* overhaul of IPython, two years in the making. Most of
9 9 the code base has been rewritten or at least reorganized, breaking backward compatibility
10 10 with several APIs in previous versions. It is the first major release in two years, and
11 11 probably the most significant change to IPython since its inception.
12 12 As a result of the significant changes, we do plan to have a relatively quick
13 13 succession of releases, as people discover new bugs and regressions.
14 14
15 15
16 16 Authors
17 17 -------
18 18
19 19 Many users and developers contributed code, features, bug reports and ideas to
20 20 this release. Please do not hesitate in contacting us if we've failed to
21 21 acknowledge your contribution here. In particular, for this release we have
22 22 contribution from the following people, a mix of new and regular names (in
23 23 alphabetical order by first name):
24 24
25 25
26 26 * Andy Wilson <wilson.andrew.j+github-at-gmail.com>
27 27 * Aenugu Sai Kiran Reddy <saikrn08-at-gmail.com>
28 28 * Antonio Cuni <antocuni>
29 29 * Barry Wark <barrywark-at-gmail.com>
30 30 * Beetoju Anuradha <anu.beethoju-at-gmail.com>
31 31 * Brad Reisfeld
32 32 * Brian Granger <ellisonbg-at-gmail.com>
33 33 * Cody Precord
34 34 * Darren Dale <dsdale24-at-gmail.com>
35 35 * Dav Clark <davclark-at-berkeley.edu>
36 36 * David Warde-Farley <wardefar-at-iro.umontreal.ca>
37 37 * Eric Firing <efiring-at-hawaii.edu>
38 38 * Erik Tollerud <erik.tollerud-at-gmail.com>
39 39 * Evan Patterson <ejpatters-at-gmail.com>
40 40 * Fernando Perez <Fernando.Perez-at-berkeley.edu>
41 41 * Gael Varoquaux <gael.varoquaux-at-normalesup.org>
42 42 * Gerardo <muzgash-at-Muzpelheim>
43 43 * Jason Grout <jason.grout-at-drake.edu>
44 44 * Jens Hedegaard Nielsen <jenshnielsen-at-gmail.com>
45 45 * Justin Riley <justin.t.riley-at-gmail.com>
46 46 * JΓΆrgen Stenarson <jorgen.stenarson-at-bostream.nu>
47 47 * Kiorky
48 48 * Laurent Dufrechou <laurent.dufrechou-at-gmail.com>
49 49 * Luis Pedro Coelho <luis-at-luispedro.org>
50 50 * Mani chandra <mchandra-at-iitk.ac.in>
51 51 * Mark E. Smith
52 52 * Mark Voorhies <mark.voorhies-at-ucsf.edu>
53 53 * Martin Spacek <git-at-mspacek.mm.st>
54 54 * Michael Droettboom <mdroe-at-stsci.edu>
55 55 * Min RK <benjaminrk-at-gmail.com>
56 56 * Nick Tarleton <nick-at-quixey.com>
57 57 * Nicolas Rougier <Nicolas.rougier-at-inria.fr>
58 58 * Omar Andres Zapata Mesa <andresete.chaos-at-gmail.com>
59 59 * Paul Ivanov <pivanov314-at-gmail.com>
60 60 * Pauli Virtanen <pauli.virtanen-at-iki.fi>
61 61 * Prabhu Ramachandran
62 62 * Ramana <sramana9-at-gmail.com>
63 63 * Robert Kern <robert.kern-at-gmail.com>
64 64 * Sathesh Chandra <satheshchandra88-at-gmail.com>
65 65 * Satrajit Ghosh <satra-at-mit.edu>
66 66 * Sebastian Busch
67 67 * Stefan van der Walt <bzr-at-mentat.za.net>
68 68 * Stephan Peijnik <debian-at-sp.or.at>
69 69 * Steven Bethard
70 70 * Thomas Kluyver <takowl-at-gmail.com>
71 71 * Thomas Spura <tomspur-at-fedoraproject.org>
72 72 * Tom Fetherston <tfetherston-at-aol.com>
73 73 * Tom MacWright
74 74 * Ville M. Vainio <vivainio-at-gmail.com>
75 75 * Vishal Vatsa <vishal.vatsa-at-gmail.com>
76 76 * Vishnu S G <sgvishnu777-at-gmail.com>
77 77 * Walter Doerwald <walter-at-livinglogic.de>
78 78 * dan.milstein
79 79 * muzuiget <muzuiget-at-gmail.com>
80 80 * tzanko
81 81 * vankayala sowjanya <hai.sowjanya-at-gmail.com>
82 82
83 83 .. note::
84 84
85 85 This list was generated with the output of
86 86 ``git log dev-0.11 HEAD --format='* %aN <%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u``
87 87 after some cleanup. If you should be on this list, please add yourself.
88 88
89 89
90 90 Refactoring
91 91 -----------
92 92
93 93 As of the 0.11 version of IPython, a signifiant portion of the core has been
94 94 refactored. This refactoring is founded on a number of new abstractions.
95 95 The main new classes that implement these abstractions are:
96 96
97 97 * :class:`IPython.utils.traitlets.HasTraits`.
98 98 * :class:`IPython.config.configurable.Configurable`.
99 99 * :class:`IPython.config.application.Application`.
100 100 * :class:`IPython.config.loader.ConfigLoader`.
101 101 * :class:`IPython.config.loader.Config`
102 102
103 103 We are still in the process of writing developer focused documentation about
104 104 these classes, but for now our :ref:`configuration documentation
105 105 <config_overview>` contains a high level overview of the concepts that these
106 106 classes express.
107 107
108 108 The biggest user-visible change is likely the move to using the config system to
109 109 determine the command-line arguments for IPython applications. The benefit of
110 110 this is that *all* configurable values in IPython are exposed on the
111 111 command-line, but the syntax for specifying values has changed. The gist is that
112 112 assigning values is pure Python assignment, so there is always an '=', and never
113 113 a leading '-', nor a space separating key from value. Flags exist, to set
114 114 multiple values or boolean flags, and these are always prefixed with '--', and
115 115 never take arguments.
116 116
117 117 ZMQ architecture
118 118 ----------------
119 119
120 120 There is a new GUI framework for IPython, based on a client-server model in
121 121 which multiple clients can communicate with one IPython kernel, using the
122 122 ZeroMQ messaging framework. There is already a Qt console client, which can
123 123 be started by calling ``ipython qtconsole``. The protocol is :ref:`documented
124 124 <messaging>`.
125 125
126 126 The parallel computing framework has also been rewritten using ZMQ. The
127 127 protocol is described :ref:`here <parallel_messages>`, and the code is in the
128 128 new :mod:`IPython.parallel` module.
129 129
130 130 Python 3 support
131 131 ----------------
132 132
133 133 A Python 3 version of IPython has been prepared. For the time being, this is
134 134 maintained separately and updated from the main codebase. Its code can be found
135 135 `here <https://github.com/ipython/ipython-py3k>`_. The parallel computing
136 136 components are not perfect on Python3, but most functionality appears to be
137 137 working.
138 138
139 139 Unicode
140 140 -------
141 141
142 142 Entering non-ascii characters in unicode literals (``u"€ø"``) now works properly
143 143 on all platforms. However, entering these in byte/string literals (``"€ø"``)
144 144 will not work as expected on Windows (or any platform where the terminal encoding
145 145 is not UTF-8, as it typically is for Linux & Mac OS X). You can use escape sequences
146 146 (``"\xe9\x82"``) to get bytes above 128, or use unicode literals and encode
147 147 them. This is a limitation of Python 2 which we cannot easily work around.
148 148
149 149 New features
150 150 ------------
151 151
152 152 * Added ``Bytes`` traitlet, removing ``Str``. All 'string' traitlets should
153 153 either be ``Unicode`` if a real string, or ``Bytes`` if a C-string. This
154 154 removes ambiguity and helps the Python 3 transition.
155 155
156 156 * New magic ``%loadpy`` loads a python file from disk or web URL into
157 157 the current input buffer.
158 158
159 159 * New magic ``%pastebin`` for sharing code via the 'Lodge it' pastebin.
160 160
161 161 * New magic ``%precision`` for controlling float and numpy pretty printing.
162 162
163 163 * IPython applications initiate logging, so any object can gain access to
164 164 a the logger of the currently running Application with:
165 165
166 166 .. sourcecode:: python
167 167
168 168 from IPython.config.application import Application
169 169 logger = Application.instance().log
170 170
171 171 * You can now get help on an object halfway through typing a command. For
172 172 instance, typing ``a = zip?`` shows the details of :func:`zip`. It also
173 173 leaves the command at the next prompt so you can carry on with it.
174 174
175 175 * The input history is now written to an SQLite database. The API for
176 176 retrieving items from the history has also been redesigned.
177 177
178 178 * The :mod:`IPython.extensions.pretty` extension has been moved out of
179 179 quarantine and fully updated to the new extension API.
180 180
181 181 * New magics for loading/unloading/reloading extensions have been added:
182 182 ``%load_ext``, ``%unload_ext`` and ``%reload_ext``.
183 183
184 184 * The configuration system and configuration files are brand new. See the
185 185 configuration system :ref:`documentation <config_index>` for more details.
186 186
187 187 * The :class:`~IPython.core.interactiveshell.InteractiveShell` class is now a
188 188 :class:`~IPython.config.configurable.Configurable` subclass and has traitlets that
189 189 determine the defaults and runtime environment. The ``__init__`` method has
190 190 also been refactored so this class can be instantiated and run without the
191 191 old :mod:`ipmaker` module.
192 192
193 193 * The methods of :class:`~IPython.core.interactiveshell.InteractiveShell` have
194 194 been organized into sections to make it easier to turn more sections
195 195 of functionality into components.
196 196
197 197 * The embedded shell has been refactored into a truly standalone subclass of
198 198 :class:`InteractiveShell` called :class:`InteractiveShellEmbed`. All
199 199 embedding logic has been taken out of the base class and put into the
200 200 embedded subclass.
201 201
202 202 * Added methods of :class:`~IPython.core.interactiveshell.InteractiveShell` to
203 203 help it cleanup after itself. The :meth:`cleanup` method controls this. We
204 204 couldn't do this in :meth:`__del__` because we have cycles in our object
205 205 graph that prevent it from being called.
206 206
207 207 * Created a new module :mod:`IPython.utils.importstring` for resolving
208 208 strings like ``foo.bar.Bar`` to the actual class.
209 209
210 210 * Completely refactored the :mod:`IPython.core.prefilter` module into
211 211 :class:`~IPython.config.configurable.Configurable` subclasses. Added a new layer
212 212 into the prefilter system, called "transformations" that all new prefilter
213 213 logic should use (rather than the older "checker/handler" approach).
214 214
215 215 * Aliases are now components (:mod:`IPython.core.alias`).
216 216
217 217 * We are now using an internally shipped version of
218 218 :mod:`~IPython.external.argparse` to parse command line options for
219 219 :command:`ipython`.
220 220
221 221 * New top level :func:`~IPython.frontend.terminal.embed.embed` function that can
222 222 be called to embed IPython at any place in user's code. One the first call it
223 223 will create an :class:`~IPython.frontend.terminal.embed.InteractiveShellEmbed`
224 224 instance and call it. In later calls, it just calls the previously created
225 225 :class:`~IPython.frontend.terminal.embed.InteractiveShellEmbed`.
226 226
227 227 * Created a configuration system (:mod:`IPython.config.configurable`) that is
228 228 based on :mod:`IPython.utils.traitlets`. Configurables are arranged into a
229 229 runtime containment tree (not inheritance) that i) automatically propagates
230 230 configuration information and ii) allows singletons to discover each other in
231 231 a loosely coupled manner. In the future all parts of IPython will be
232 232 subclasses of :class:`~IPython.config.configurable.Configurable`. All IPython
233 233 developers should become familiar with the config system.
234 234
235 235 * Created a new :class:`~IPython.config.loader.Config` for holding
236 236 configuration information. This is a dict like class with a few extras: i)
237 237 it supports attribute style access, ii) it has a merge function that merges
238 238 two :class:`~IPython.config.loader.Config` instances recursively and iii) it
239 239 will automatically create sub-:class:`~IPython.config.loader.Config`
240 240 instances for attributes that start with an uppercase character.
241 241
242 242 * Created new configuration loaders in :mod:`IPython.config.loader`. These
243 243 loaders provide a unified loading interface for all configuration
244 244 information including command line arguments and configuration files. We
245 245 have two default implementations based on :mod:`argparse` and plain python
246 246 files. These are used to implement the new configuration system.
247 247
248 248 * Created a top-level :class:`Application` class in
249 249 :mod:`IPython.core.application` that is designed to encapsulate the starting
250 250 of any basic Python program. An application loads and merges all the
251 251 configuration objects, constructs the main application, configures and
252 252 initiates logging, and creates and configures any :class:`Configurable`
253 253 instances and then starts the application running. An extended
254 254 :class:`BaseIPythonApplication` class adds logic for handling the
255 255 IPython directory as well as profiles, and all IPython entry points
256 256 extend it.
257 257
258 258 * The :class:`Type` and :class:`Instance` traitlets now handle classes given
259 259 as strings, like ``foo.bar.Bar``. This is needed for forward declarations.
260 260 But, this was implemented in a careful way so that string to class
261 261 resolution is done at a single point, when the parent
262 262 :class:`~IPython.utils.traitlets.HasTraitlets` is instantiated.
263 263
264 264 * :mod:`IPython.utils.ipstruct` has been refactored to be a subclass of
265 265 dict. It also now has full docstrings and doctests.
266 266 * Created a Trait's like implementation in :mod:`IPython.utils.traitlets`.
267 267 This is a pure Python, lightweight version of a library that is similar to
268 268 :mod:`enthought.traits`. We are using this for validation, defaults and
269 269 notification in our new component system. Although it is not API compatible
270 270 with :mod:`enthought.traits`, we plan on moving in this direction so that
271 271 eventually our implementation could be replaced by a (yet to exist) pure
272 272 Python version of :mod:`enthought.traits`.
273 273
274 274 * Added a new module :mod:`IPython.lib.inputhook` to manage the integration
275 275 with GUI event loops using `PyOS_InputHook`. See the docstrings in this
276 276 module or the main IPython docs for details.
277 277
278 278 * For users, GUI event loop integration is now handled through the new
279 279 :command:`%gui` magic command. Type ``%gui?`` at an IPython prompt for
280 280 documentation.
281 281
282 282 * For developers :mod:`IPython.lib.inputhook` provides a simple interface
283 283 for managing the event loops in their interactive GUI applications.
284 284 Examples can be found in our :file:`docs/examples/lib` directory.
285 285
286 286 Backwards incompatible changes
287 287 ------------------------------
288 288
289 289 * The Twisted-based :mod:`IPython.kernel` has been removed, and completely
290 290 rewritten as :mod:`IPython.parallel`, using ZeroMQ.
291 291
292 292 * Profiles are now directories. Instead of a profile being a single config file,
293 293 profiles are now self-contained directories. By default, profiles get their
294 294 own IPython history, log files, and everything. To create a new profile, do
295 295 ``ipython profile create <name>``.
296 296
297 297 * All IPython applications have been rewritten to use
298 298 :class:`~IPython.config.loader.KeyValueConfigLoader`. This means that
299 299 command-line options have changed. Now, all configurable values are accessible
300 300 from the command-line with the same syntax as in a configuration file.
301 301
302 302 * The command line options ``-wthread``, ``-qthread`` and
303 303 ``-gthread`` have been removed. Use ``gui=wx``, ``gui=qt``, ``gui=gtk``
304 304 instead.
305 305
306 306 * The extension loading functions have been renamed to
307 307 :func:`load_ipython_extension` and :func:`unload_ipython_extension`.
308 308
309 309 * :class:`~IPython.core.interactiveshell.InteractiveShell` no longer takes an
310 310 ``embedded`` argument. Instead just use the
311 311 :class:`~IPython.core.interactiveshell.InteractiveShellEmbed` class.
312 312
313 313 * ``__IPYTHON__`` is no longer injected into ``__builtin__``.
314 314
315 315 * :meth:`Struct.__init__` no longer takes `None` as its first argument. It
316 316 must be a :class:`dict` or :class:`Struct`.
317 317
318 318 * :meth:`~IPython.core.interactiveshell.InteractiveShell.ipmagic` has been
319 319 renamed :meth:`~IPython.core.interactiveshell.InteractiveShell.magic.`
320 320
321 321 * The functions :func:`ipmagic` and :func:`ipalias` have been removed from
322 322 :mod:`__builtins__`.
323 323
324 324 * The references to the global
325 325 :class:`~IPython.core.interactivehell.InteractiveShell` instance (``_ip``, and
326 326 ``__IP``) have been removed from the user's namespace. They are replaced by a
327 327 new function called :func:`get_ipython` that returns the current
328 328 :class:`~IPython.core.interactiveshell.InteractiveShell` instance. This
329 329 function is injected into the user's namespace and is now the main way of
330 330 accessing the running IPython.
331 331
332 332 * Old style configuration files :file:`ipythonrc` and :file:`ipy_user_conf.py`
333 333 are no longer supported. Users should migrate there configuration files to
334 334 the new format described :ref:`here <config_overview>` and :ref:`here
335 335 <configuring_ipython>`.
336 336
337 337 * The old IPython extension API that relied on :func:`ipapi` has been
338 338 completely removed. The new extension API is described :ref:`here
339 339 <configuring_ipython>`.
340 340
341 341 * Support for ``qt3`` has been dropped. Users who need this should use
342 342 previous versions of IPython.
343 343
344 344 * Removed :mod:`shellglobals` as it was obsolete.
345 345
346 346 * Removed all the threaded shells in :mod:`IPython.core.shell`. These are no
347 347 longer needed because of the new capabilities in
348 348 :mod:`IPython.lib.inputhook`.
349 349
350 350 * New top-level sub-packages have been created: :mod:`IPython.core`,
351 351 :mod:`IPython.lib`, :mod:`IPython.utils`, :mod:`IPython.deathrow`,
352 352 :mod:`IPython.quarantine`. All existing top-level modules have been
353 353 moved to appropriate sub-packages. All internal import statements
354 354 have been updated and tests have been added. The build system (setup.py
355 355 and friends) have been updated. See :ref:`this section <module_reorg>` of the
356 356 documentation for descriptions of these new sub-packages.
357 357
358 358 * :mod:`IPython.ipapi` has been moved to :mod:`IPython.core.ipapi`.
359 359 :mod:`IPython.Shell` and :mod:`IPython.iplib` have been split and removed as
360 360 part of the refactor.
361 361
362 362 * :mod:`Extensions` has been moved to :mod:`extensions` and all existing
363 363 extensions have been moved to either :mod:`IPython.quarantine` or
364 364 :mod:`IPython.deathrow`. :mod:`IPython.quarantine` contains modules that we
365 365 plan on keeping but that need to be updated. :mod:`IPython.deathrow`
366 366 contains modules that are either dead or that should be maintained as third
367 367 party libraries. More details about this can be found :ref:`here
368 368 <module_reorg>`.
369 369
370 370 * Previous IPython GUIs in :mod:`IPython.frontend` and :mod:`IPython.gui` are
371 371 likely broken, and have been removed to :mod:`IPython.deathrow` because of the
372 372 refactoring in the core. With proper updates, these should still work.
373 373
374 374
375 375 Known Regressions
376 376 -----------------
377 377
378 378 We do our best to improve IPython, but there are some known regressions in 0.11 relative
379 379 to 0.10.2.
380 380
381 381 * The machinery that adds functionality to the 'sh' profile for using IPython as your
382 382 system shell has not been updated to use the new APIs. As a result, only the aesthetic
383 383 (prompt) changes are still implemented. We intend to fix this by 0.12.
384 384
385 385 * The installation of scripts on Windows was broken without setuptools, so we now
386 386 depend on setuptools on Windows. We hope to fix setuptools-less installation,
387 387 and then remove the setuptools dependency.
388
389 * Capitalised Exit and Quit have been dropped ways to exit IPython. The lowercase forms
390 of both work either as a bare name (``exit``) or a function call (``exit()``).
391 You can assign these to other names using exec_lines in the config file.
General Comments 0
You need to be logged in to leave comments. Login now