Show More
@@ -1,391 +1,549 b'' | |||
|
1 |
============= |
|
|
2 | 0.11 Series | |
|
3 |
============= |
|
|
1 | ============= | |
|
2 | 0.11 Series | |
|
3 | ============= | |
|
4 | 4 | |
|
5 | 5 | Release 0.11 |
|
6 | 6 | ============ |
|
7 | 7 | |
|
8 |
IPython 0.11 is a *major* overhaul of IPython, two years in the making. Most |
|
|
9 |
the code base has been rewritten or at least reorganized, breaking backward |
|
|
10 |
with several APIs in previous versions. It is the first major |
|
|
11 |
probably the most significant change to IPython since |
|
|
12 | As a result of the significant changes, we do plan to have a relatively quick | |
|
13 | succession of releases, as people discover new bugs and regressions. | |
|
8 | IPython 0.11 is a *major* overhaul of IPython, two years in the making. Most | |
|
9 | of the code base has been rewritten or at least reorganized, breaking backward | |
|
10 | compatibility with several APIs in previous versions. It is the first major | |
|
11 | release in two years, and probably the most significant change to IPython since | |
|
12 | its inception. We plan to have a relatively quick succession of releases, as | |
|
13 | people discover new bugs and regressions. Once we iron out any significant | |
|
14 | bugs in this process and settle down the new APIs, this series will become | |
|
15 | IPython 1.0. We encourage feedback now on the core APIs, which we hope to | |
|
16 | maintain stable during the 1.0 series. | |
|
14 | 17 | |
|
18 | Chris Fonnesbeck recently wrote an `excellent post`_ that highlights some of | |
|
19 | the core new features, with examples and screenshots. We encourage you | |
|
20 | to read it as it provides a great high-level overview that complements the | |
|
21 | detailed feature breakdown in this document. | |
|
15 | 22 | |
|
16 | Authors | |
|
17 | ------- | |
|
23 | .. _excellent post: http://stronginference.com/weblog/2011/7/15/innovations-in-ipython.html | |
|
18 | 24 | |
|
19 | Many users and developers contributed code, features, bug reports and ideas to | |
|
20 | this release. Please do not hesitate in contacting us if we've failed to | |
|
21 | acknowledge your contribution here. In particular, for this release we have | |
|
22 | contribution from the following people, a mix of new and regular names (in | |
|
23 | alphabetical order by first name): | |
|
25 | A quick summary of the major changes (see below for details): | |
|
24 | 26 | |
|
27 | * *Standalone Qt console*: a new rich console has been added to IPython, started | |
|
28 | with `ipython qtconsole`. In this application we have tried to retain the | |
|
29 | feel of a terminal for fast and efficient workflows, while adding many | |
|
30 | features that a plain text terminal simply can not support, such as inline | |
|
31 | figures, full multiline editing with syntax highlighting, tooltips for | |
|
32 | function calls and much more. | |
|
25 | 33 | |
|
26 | * Andy Wilson <wilson.andrew.j+github-at-gmail.com> | |
|
27 | * Aenugu Sai Kiran Reddy <saikrn08-at-gmail.com> | |
|
28 | * Antonio Cuni <antocuni> | |
|
29 | * Barry Wark <barrywark-at-gmail.com> | |
|
30 | * Beetoju Anuradha <anu.beethoju-at-gmail.com> | |
|
31 | * Brad Reisfeld | |
|
32 | * Brian Granger <ellisonbg-at-gmail.com> | |
|
33 | * Cody Precord | |
|
34 | * Darren Dale <dsdale24-at-gmail.com> | |
|
35 | * Dav Clark <davclark-at-berkeley.edu> | |
|
36 | * David Warde-Farley <wardefar-at-iro.umontreal.ca> | |
|
37 | * Eric Firing <efiring-at-hawaii.edu> | |
|
38 | * Erik Tollerud <erik.tollerud-at-gmail.com> | |
|
39 | * Evan Patterson <ejpatters-at-gmail.com> | |
|
40 | * Fernando Perez <Fernando.Perez-at-berkeley.edu> | |
|
41 | * Gael Varoquaux <gael.varoquaux-at-normalesup.org> | |
|
42 | * Gerardo <muzgash-at-Muzpelheim> | |
|
43 | * Jason Grout <jason.grout-at-drake.edu> | |
|
44 | * Jens Hedegaard Nielsen <jenshnielsen-at-gmail.com> | |
|
45 | * Justin Riley <justin.t.riley-at-gmail.com> | |
|
46 | * Jörgen Stenarson <jorgen.stenarson-at-bostream.nu> | |
|
47 | * Kiorky | |
|
48 | * Laurent Dufrechou <laurent.dufrechou-at-gmail.com> | |
|
49 | * Luis Pedro Coelho <luis-at-luispedro.org> | |
|
50 | * Mani chandra <mchandra-at-iitk.ac.in> | |
|
51 | * Mark E. Smith | |
|
52 | * Mark Voorhies <mark.voorhies-at-ucsf.edu> | |
|
53 | * Martin Spacek <git-at-mspacek.mm.st> | |
|
54 | * Michael Droettboom <mdroe-at-stsci.edu> | |
|
55 | * Min RK <benjaminrk-at-gmail.com> | |
|
56 | * Nick Tarleton <nick-at-quixey.com> | |
|
57 | * Nicolas Rougier <Nicolas.rougier-at-inria.fr> | |
|
58 | * Omar Andres Zapata Mesa <andresete.chaos-at-gmail.com> | |
|
59 | * Paul Ivanov <pivanov314-at-gmail.com> | |
|
60 | * Pauli Virtanen <pauli.virtanen-at-iki.fi> | |
|
61 | * Prabhu Ramachandran | |
|
62 | * Ramana <sramana9-at-gmail.com> | |
|
63 | * Robert Kern <robert.kern-at-gmail.com> | |
|
64 | * Sathesh Chandra <satheshchandra88-at-gmail.com> | |
|
65 | * Satrajit Ghosh <satra-at-mit.edu> | |
|
66 | * Sebastian Busch | |
|
67 | * Stefan van der Walt <bzr-at-mentat.za.net> | |
|
68 | * Stephan Peijnik <debian-at-sp.or.at> | |
|
69 | * Steven Bethard | |
|
70 | * Thomas Kluyver <takowl-at-gmail.com> | |
|
71 | * Thomas Spura <tomspur-at-fedoraproject.org> | |
|
72 | * Tom Fetherston <tfetherston-at-aol.com> | |
|
73 | * Tom MacWright | |
|
74 | * Ville M. Vainio <vivainio-at-gmail.com> | |
|
75 | * Vishal Vatsa <vishal.vatsa-at-gmail.com> | |
|
76 | * Vishnu S G <sgvishnu777-at-gmail.com> | |
|
77 | * Walter Doerwald <walter-at-livinglogic.de> | |
|
78 | * dan.milstein | |
|
79 | * muzuiget <muzuiget-at-gmail.com> | |
|
80 | * tzanko | |
|
81 | * vankayala sowjanya <hai.sowjanya-at-gmail.com> | |
|
34 | * *High-level parallel computing with ZeroMQ*. Using the same architecture that | |
|
35 | our Qt console is based on, we have completely rewritten our high-level | |
|
36 | parallel computing machinery that in prior versions used the Twisted | |
|
37 | networking framework. While this change will require users to update their | |
|
38 | codes, the improvements in performance, memory control and internal | |
|
39 | consistency across our codebase convinced us it was a price worth paying. We | |
|
40 | have tried to explain how to best proceed with this update, and will be happy | |
|
41 | to answer questions that may arise. | |
|
82 | 42 | |
|
83 | .. note:: | |
|
43 | * *New model for GUI/plotting support in the terminal*. Now instead of the | |
|
44 | various `-Xthread` flags we had before, GUI support is provided without the | |
|
45 | use of any threads, by directly integrating GUI event loops with Python's | |
|
46 | `PyOS_InputHook` API. A new command-line flag `--gui` controls GUI support, | |
|
47 | and it can also be enabled after IPython startup via the new `%gui` magic. | |
|
84 | 48 | |
|
85 | This list was generated with the output of | |
|
86 | ``git log dev-0.11 HEAD --format='* %aN <%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u`` | |
|
87 | after some cleanup. If you should be on this list, please add yourself. | |
|
49 | * *A two-process architecture.* The Qt console is the first example of using a | |
|
50 | new model that splits IPython between a kernel process where code is executed | |
|
51 | and a client that handles user interaction. We plan on also providing | |
|
52 | terminal and web-browser based clients using this infrastructure in future | |
|
53 | releases. This model allows multiple clients to interact with an IPython | |
|
54 | process through a well-documented protocol using the ZeroMQ networking | |
|
55 | library. | |
|
56 | ||
|
57 | * *Refactoring.* the entire codebase has been refactored, in order to make it | |
|
58 | more modular and easier to contribute to. IPython has traditionally been a | |
|
59 | hard project to participate because the old codebase was very monolithic. We | |
|
60 | hope this (ongoing) restructuring will make it easier for new developers to | |
|
61 | join us. | |
|
62 | ||
|
63 | * *Improved unicode support*. We closed many bugs related to unicode input. | |
|
64 | ||
|
65 | * *Python 3*. IPython now runs on Python 3.x. | |
|
66 | ||
|
67 | * *New profile model*. Profiles are now directories that contain all relevant | |
|
68 | infromation for that session, and thus better isolate IPython use-cases. | |
|
69 | ||
|
70 | * *SQLite storage for history*. All history is now stored in a SQLite database, | |
|
71 | providing support for multiple simultaneous sessions that won't clobber each | |
|
72 | other as well as the ability to perform queries on all stored data. | |
|
73 | ||
|
74 | * *New configuration system*. All parts of IPython are now configured via a | |
|
75 | mechanism inspired by the Enthought Traits library. Any configurable | |
|
76 | element can have its attributes set either via files that now use real | |
|
77 | Python syntax or from the command-line. | |
|
78 | ||
|
79 | ||
|
80 | Over 60 separate authors have contributed to this release, see :ref:`below | |
|
81 | <credits>` for a full list. | |
|
82 | ||
|
83 | ||
|
84 | Plotting and GUI support in the terminal | |
|
85 | ---------------------------------------- | |
|
86 | ||
|
87 | blah | |
|
88 | ||
|
89 | ||
|
90 | Qt Console | |
|
91 | ---------- | |
|
92 | ||
|
93 | blah | |
|
94 | ||
|
95 | ||
|
96 | High-level parallel computing with ZeroMQ | |
|
97 | ----------------------------------------- | |
|
88 | 98 | |
|
89 | 99 | |
|
90 | 100 | Refactoring |
|
91 | 101 | ----------- |
|
92 | 102 | |
|
93 | 103 | As of the 0.11 version of IPython, a signifiant portion of the core has been |
|
94 | 104 | refactored. This refactoring is founded on a number of new abstractions. |
|
95 | 105 | The main new classes that implement these abstractions are: |
|
96 | 106 | |
|
97 | 107 | * :class:`IPython.utils.traitlets.HasTraits`. |
|
98 | 108 | * :class:`IPython.config.configurable.Configurable`. |
|
99 | 109 | * :class:`IPython.config.application.Application`. |
|
100 | 110 | * :class:`IPython.config.loader.ConfigLoader`. |
|
101 | 111 | * :class:`IPython.config.loader.Config` |
|
102 | 112 | |
|
103 | 113 | We are still in the process of writing developer focused documentation about |
|
104 | 114 | these classes, but for now our :ref:`configuration documentation |
|
105 | 115 | <config_overview>` contains a high level overview of the concepts that these |
|
106 | 116 | classes express. |
|
107 | 117 | |
|
108 | 118 | The biggest user-visible change is likely the move to using the config system to |
|
109 | 119 | determine the command-line arguments for IPython applications. The benefit of |
|
110 | 120 | this is that *all* configurable values in IPython are exposed on the |
|
111 | 121 | command-line, but the syntax for specifying values has changed. The gist is that |
|
112 | 122 | assigning values is pure Python assignment, so there is always an '=', and never |
|
113 | 123 | a leading '-', nor a space separating key from value. Flags exist, to set |
|
114 | 124 | multiple values or boolean flags, and these are always prefixed with '--', and |
|
115 | 125 | never take arguments. |
|
116 | 126 | |
|
117 | 127 | ZMQ architecture |
|
118 | 128 | ---------------- |
|
119 | 129 | |
|
120 | 130 | There is a new GUI framework for IPython, based on a client-server model in |
|
121 | 131 | which multiple clients can communicate with one IPython kernel, using the |
|
122 | 132 | ZeroMQ messaging framework. There is already a Qt console client, which can |
|
123 | 133 | be started by calling ``ipython qtconsole``. The protocol is :ref:`documented |
|
124 | 134 | <messaging>`. |
|
125 | 135 | |
|
126 | 136 | The parallel computing framework has also been rewritten using ZMQ. The |
|
127 | 137 | protocol is described :ref:`here <parallel_messages>`, and the code is in the |
|
128 | 138 | new :mod:`IPython.parallel` module. |
|
129 | 139 | |
|
130 | 140 | Python 3 support |
|
131 | 141 | ---------------- |
|
132 | 142 | |
|
133 | 143 | A Python 3 version of IPython has been prepared. For the time being, this is |
|
134 | 144 | maintained separately and updated from the main codebase. Its code can be found |
|
135 | 145 | `here <https://github.com/ipython/ipython-py3k>`_. The parallel computing |
|
136 | 146 | components are not perfect on Python3, but most functionality appears to be |
|
137 | 147 | working. |
|
138 | 148 | |
|
139 | 149 | Unicode |
|
140 | 150 | ------- |
|
141 | 151 | |
|
142 |
Entering non-ascii characters in unicode literals (``u"€ø"``) now works |
|
|
143 |
on all platforms. However, entering these in byte/string literals |
|
|
144 |
will not work as expected on Windows (or any platform where the |
|
|
145 |
is not UTF-8, as it typically is for Linux & Mac OS X). You |
|
|
146 |
(``"\xe9\x82"``) to get bytes above 128, or use |
|
|
147 |
them. This is a limitation of Python 2 which we |
|
|
152 | Entering non-ascii characters in unicode literals (``u"€ø"``) now works | |
|
153 | properly on all platforms. However, entering these in byte/string literals | |
|
154 | (``"€ø"``) will not work as expected on Windows (or any platform where the | |
|
155 | terminal encoding is not UTF-8, as it typically is for Linux & Mac OS X). You | |
|
156 | can use escape sequences (``"\xe9\x82"``) to get bytes above 128, or use | |
|
157 | unicode literals and encode them. This is a limitation of Python 2 which we | |
|
158 | cannot easily work around. | |
|
148 | 159 | |
|
149 |
|
|
|
150 | ------------ | |
|
160 | Additional new features | |
|
161 | ----------------------- | |
|
151 | 162 | |
|
152 | 163 | * Added ``Bytes`` traitlet, removing ``Str``. All 'string' traitlets should |
|
153 | 164 | either be ``Unicode`` if a real string, or ``Bytes`` if a C-string. This |
|
154 | 165 | removes ambiguity and helps the Python 3 transition. |
|
155 | 166 | |
|
156 | 167 | * New magic ``%loadpy`` loads a python file from disk or web URL into |
|
157 | 168 | the current input buffer. |
|
158 | 169 | |
|
159 | 170 | * New magic ``%pastebin`` for sharing code via the 'Lodge it' pastebin. |
|
160 | 171 | |
|
161 | 172 | * New magic ``%precision`` for controlling float and numpy pretty printing. |
|
162 | 173 | |
|
163 | 174 | * IPython applications initiate logging, so any object can gain access to |
|
164 | 175 | a the logger of the currently running Application with: |
|
165 | 176 | |
|
166 | 177 | .. sourcecode:: python |
|
167 | 178 | |
|
168 | 179 | from IPython.config.application import Application |
|
169 | 180 | logger = Application.instance().log |
|
170 | 181 | |
|
171 | 182 | * You can now get help on an object halfway through typing a command. For |
|
172 | 183 | instance, typing ``a = zip?`` shows the details of :func:`zip`. It also |
|
173 | 184 | leaves the command at the next prompt so you can carry on with it. |
|
174 | 185 | |
|
175 | 186 | * The input history is now written to an SQLite database. The API for |
|
176 | 187 | retrieving items from the history has also been redesigned. |
|
177 | 188 | |
|
178 | 189 | * The :mod:`IPython.extensions.pretty` extension has been moved out of |
|
179 | 190 | quarantine and fully updated to the new extension API. |
|
180 | 191 | |
|
181 | 192 | * New magics for loading/unloading/reloading extensions have been added: |
|
182 | 193 | ``%load_ext``, ``%unload_ext`` and ``%reload_ext``. |
|
183 | 194 | |
|
184 | 195 | * The configuration system and configuration files are brand new. See the |
|
185 | 196 | configuration system :ref:`documentation <config_index>` for more details. |
|
186 | 197 | |
|
187 | 198 | * The :class:`~IPython.core.interactiveshell.InteractiveShell` class is now a |
|
188 |
:class:`~IPython.config.configurable.Configurable` subclass and has traitlets |
|
|
189 |
determine the defaults and runtime environment. The ``__init__`` method |
|
|
190 |
also been refactored so this class can be instantiated and run without |
|
|
191 | old :mod:`ipmaker` module. | |
|
199 | :class:`~IPython.config.configurable.Configurable` subclass and has traitlets | |
|
200 | that determine the defaults and runtime environment. The ``__init__`` method | |
|
201 | has also been refactored so this class can be instantiated and run without | |
|
202 | the old :mod:`ipmaker` module. | |
|
192 | 203 | |
|
193 | 204 | * The methods of :class:`~IPython.core.interactiveshell.InteractiveShell` have |
|
194 | 205 | been organized into sections to make it easier to turn more sections |
|
195 | 206 | of functionality into components. |
|
196 | 207 | |
|
197 | 208 | * The embedded shell has been refactored into a truly standalone subclass of |
|
198 | 209 | :class:`InteractiveShell` called :class:`InteractiveShellEmbed`. All |
|
199 | 210 | embedding logic has been taken out of the base class and put into the |
|
200 | 211 | embedded subclass. |
|
201 | 212 | |
|
202 | 213 | * Added methods of :class:`~IPython.core.interactiveshell.InteractiveShell` to |
|
203 | 214 | help it cleanup after itself. The :meth:`cleanup` method controls this. We |
|
204 | 215 | couldn't do this in :meth:`__del__` because we have cycles in our object |
|
205 | 216 | graph that prevent it from being called. |
|
206 | 217 | |
|
207 | 218 | * Created a new module :mod:`IPython.utils.importstring` for resolving |
|
208 | 219 | strings like ``foo.bar.Bar`` to the actual class. |
|
209 | 220 | |
|
210 | 221 | * Completely refactored the :mod:`IPython.core.prefilter` module into |
|
211 |
:class:`~IPython.config.configurable.Configurable` subclasses. Added a new |
|
|
212 |
into the prefilter system, called "transformations" that all new |
|
|
213 |
logic should use (rather than the older "checker/handler" |
|
|
222 | :class:`~IPython.config.configurable.Configurable` subclasses. Added a new | |
|
223 | layer into the prefilter system, called "transformations" that all new | |
|
224 | prefilter logic should use (rather than the older "checker/handler" | |
|
225 | approach). | |
|
214 | 226 | |
|
215 | 227 | * Aliases are now components (:mod:`IPython.core.alias`). |
|
216 | 228 | |
|
217 | * We are now using an internally shipped version of | |
|
218 | :mod:`~IPython.external.argparse` to parse command line options for | |
|
219 | :command:`ipython`. | |
|
220 | ||
|
221 | 229 | * New top level :func:`~IPython.frontend.terminal.embed.embed` function that can |
|
222 |
be called to embed IPython at any place in user's code. On |
|
|
230 | be called to embed IPython at any place in user's code. On the first call it | |
|
223 | 231 | will create an :class:`~IPython.frontend.terminal.embed.InteractiveShellEmbed` |
|
224 | 232 | instance and call it. In later calls, it just calls the previously created |
|
225 | 233 | :class:`~IPython.frontend.terminal.embed.InteractiveShellEmbed`. |
|
226 | 234 | |
|
227 | 235 | * Created a configuration system (:mod:`IPython.config.configurable`) that is |
|
228 | 236 | based on :mod:`IPython.utils.traitlets`. Configurables are arranged into a |
|
229 | 237 | runtime containment tree (not inheritance) that i) automatically propagates |
|
230 | 238 | configuration information and ii) allows singletons to discover each other in |
|
231 | 239 | a loosely coupled manner. In the future all parts of IPython will be |
|
232 | 240 | subclasses of :class:`~IPython.config.configurable.Configurable`. All IPython |
|
233 | 241 | developers should become familiar with the config system. |
|
234 | 242 | |
|
235 | 243 | * Created a new :class:`~IPython.config.loader.Config` for holding |
|
236 | 244 | configuration information. This is a dict like class with a few extras: i) |
|
237 | 245 | it supports attribute style access, ii) it has a merge function that merges |
|
238 | 246 | two :class:`~IPython.config.loader.Config` instances recursively and iii) it |
|
239 | 247 | will automatically create sub-:class:`~IPython.config.loader.Config` |
|
240 | 248 | instances for attributes that start with an uppercase character. |
|
241 | 249 | |
|
242 | 250 | * Created new configuration loaders in :mod:`IPython.config.loader`. These |
|
243 | 251 | loaders provide a unified loading interface for all configuration |
|
244 | 252 | information including command line arguments and configuration files. We |
|
245 | 253 | have two default implementations based on :mod:`argparse` and plain python |
|
246 | 254 | files. These are used to implement the new configuration system. |
|
247 | 255 | |
|
248 | 256 | * Created a top-level :class:`Application` class in |
|
249 | 257 | :mod:`IPython.core.application` that is designed to encapsulate the starting |
|
250 | 258 | of any basic Python program. An application loads and merges all the |
|
251 | 259 | configuration objects, constructs the main application, configures and |
|
252 | 260 | initiates logging, and creates and configures any :class:`Configurable` |
|
253 | 261 | instances and then starts the application running. An extended |
|
254 | 262 | :class:`BaseIPythonApplication` class adds logic for handling the |
|
255 | 263 | IPython directory as well as profiles, and all IPython entry points |
|
256 | 264 | extend it. |
|
257 | 265 | |
|
258 | 266 | * The :class:`Type` and :class:`Instance` traitlets now handle classes given |
|
259 | 267 | as strings, like ``foo.bar.Bar``. This is needed for forward declarations. |
|
260 | 268 | But, this was implemented in a careful way so that string to class |
|
261 | 269 | resolution is done at a single point, when the parent |
|
262 | 270 | :class:`~IPython.utils.traitlets.HasTraitlets` is instantiated. |
|
263 | 271 | |
|
264 | 272 | * :mod:`IPython.utils.ipstruct` has been refactored to be a subclass of |
|
265 | 273 | dict. It also now has full docstrings and doctests. |
|
266 | * Created a Trait's like implementation in :mod:`IPython.utils.traitlets`. | |
|
267 | This is a pure Python, lightweight version of a library that is similar to | |
|
268 | :mod:`enthought.traits`. We are using this for validation, defaults and | |
|
269 | notification in our new component system. Although it is not API compatible | |
|
270 | with :mod:`enthought.traits`, we plan on moving in this direction so that | |
|
271 | eventually our implementation could be replaced by a (yet to exist) pure | |
|
272 | Python version of :mod:`enthought.traits`. | |
|
274 | ||
|
275 | * Created a Traits like implementation in :mod:`IPython.utils.traitlets`. This | |
|
276 | is a pure Python, lightweight version of a library that is similar to | |
|
277 | Enthought's Traits project, but has no dependencies on Enthought's code. We | |
|
278 | are using this for validation, defaults and notification in our new component | |
|
279 | system. Although it is not 100% API compatible with Enthought's Traits, we | |
|
280 | plan on moving in this direction so that eventually our implementation could | |
|
281 | be replaced by a (yet to exist) pure Python version of Enthought Traits. | |
|
273 | 282 | |
|
274 | 283 | * Added a new module :mod:`IPython.lib.inputhook` to manage the integration |
|
275 | 284 | with GUI event loops using `PyOS_InputHook`. See the docstrings in this |
|
276 | 285 | module or the main IPython docs for details. |
|
277 | 286 | |
|
278 | 287 | * For users, GUI event loop integration is now handled through the new |
|
279 | 288 | :command:`%gui` magic command. Type ``%gui?`` at an IPython prompt for |
|
280 | 289 | documentation. |
|
281 | 290 | |
|
282 | 291 | * For developers :mod:`IPython.lib.inputhook` provides a simple interface |
|
283 | 292 | for managing the event loops in their interactive GUI applications. |
|
284 | 293 | Examples can be found in our :file:`docs/examples/lib` directory. |
|
285 | 294 | |
|
286 | 295 | Backwards incompatible changes |
|
287 | 296 | ------------------------------ |
|
288 | 297 | |
|
289 | 298 | * The Twisted-based :mod:`IPython.kernel` has been removed, and completely |
|
290 | 299 | rewritten as :mod:`IPython.parallel`, using ZeroMQ. |
|
291 | 300 | |
|
292 | 301 | * Profiles are now directories. Instead of a profile being a single config file, |
|
293 | 302 | profiles are now self-contained directories. By default, profiles get their |
|
294 | 303 | own IPython history, log files, and everything. To create a new profile, do |
|
295 | 304 | ``ipython profile create <name>``. |
|
296 | 305 | |
|
297 | 306 | * All IPython applications have been rewritten to use |
|
298 | 307 | :class:`~IPython.config.loader.KeyValueConfigLoader`. This means that |
|
299 | 308 | command-line options have changed. Now, all configurable values are accessible |
|
300 | 309 | from the command-line with the same syntax as in a configuration file. |
|
301 | 310 | |
|
302 | 311 | * The command line options ``-wthread``, ``-qthread`` and |
|
303 | 312 | ``-gthread`` have been removed. Use ``--gui=wx``, ``--gui=qt``, ``--gui=gtk`` |
|
304 | 313 | instead. |
|
305 | 314 | |
|
306 | 315 | * The extension loading functions have been renamed to |
|
307 | 316 | :func:`load_ipython_extension` and :func:`unload_ipython_extension`. |
|
308 | 317 | |
|
309 | 318 | * :class:`~IPython.core.interactiveshell.InteractiveShell` no longer takes an |
|
310 | 319 | ``embedded`` argument. Instead just use the |
|
311 | 320 | :class:`~IPython.core.interactiveshell.InteractiveShellEmbed` class. |
|
312 | 321 | |
|
313 | 322 | * ``__IPYTHON__`` is no longer injected into ``__builtin__``. |
|
314 | 323 | |
|
315 | 324 | * :meth:`Struct.__init__` no longer takes `None` as its first argument. It |
|
316 | 325 | must be a :class:`dict` or :class:`Struct`. |
|
317 | 326 | |
|
318 | 327 | * :meth:`~IPython.core.interactiveshell.InteractiveShell.ipmagic` has been |
|
319 | 328 | renamed :meth:`~IPython.core.interactiveshell.InteractiveShell.magic.` |
|
320 | 329 | |
|
321 | 330 | * The functions :func:`ipmagic` and :func:`ipalias` have been removed from |
|
322 | 331 | :mod:`__builtins__`. |
|
323 | 332 | |
|
324 | 333 | * The references to the global |
|
325 | 334 | :class:`~IPython.core.interactivehell.InteractiveShell` instance (``_ip``, and |
|
326 | 335 | ``__IP``) have been removed from the user's namespace. They are replaced by a |
|
327 | 336 | new function called :func:`get_ipython` that returns the current |
|
328 | 337 | :class:`~IPython.core.interactiveshell.InteractiveShell` instance. This |
|
329 | 338 | function is injected into the user's namespace and is now the main way of |
|
330 | 339 | accessing the running IPython. |
|
331 | 340 | |
|
332 | 341 | * Old style configuration files :file:`ipythonrc` and :file:`ipy_user_conf.py` |
|
333 | 342 | are no longer supported. Users should migrate there configuration files to |
|
334 | 343 | the new format described :ref:`here <config_overview>` and :ref:`here |
|
335 | 344 | <configuring_ipython>`. |
|
336 | 345 | |
|
337 | 346 | * The old IPython extension API that relied on :func:`ipapi` has been |
|
338 | 347 | completely removed. The new extension API is described :ref:`here |
|
339 | 348 | <configuring_ipython>`. |
|
340 | 349 | |
|
341 | 350 | * Support for ``qt3`` has been dropped. Users who need this should use |
|
342 | 351 | previous versions of IPython. |
|
343 | 352 | |
|
344 | 353 | * Removed :mod:`shellglobals` as it was obsolete. |
|
345 | 354 | |
|
346 | 355 | * Removed all the threaded shells in :mod:`IPython.core.shell`. These are no |
|
347 | 356 | longer needed because of the new capabilities in |
|
348 | 357 | :mod:`IPython.lib.inputhook`. |
|
349 | 358 | |
|
350 | 359 | * New top-level sub-packages have been created: :mod:`IPython.core`, |
|
351 | 360 | :mod:`IPython.lib`, :mod:`IPython.utils`, :mod:`IPython.deathrow`, |
|
352 | 361 | :mod:`IPython.quarantine`. All existing top-level modules have been |
|
353 | 362 | moved to appropriate sub-packages. All internal import statements |
|
354 | 363 | have been updated and tests have been added. The build system (setup.py |
|
355 | 364 | and friends) have been updated. See :ref:`this section <module_reorg>` of the |
|
356 | 365 | documentation for descriptions of these new sub-packages. |
|
357 | 366 | |
|
358 | 367 | * :mod:`IPython.ipapi` has been moved to :mod:`IPython.core.ipapi`. |
|
359 | 368 | :mod:`IPython.Shell` and :mod:`IPython.iplib` have been split and removed as |
|
360 | 369 | part of the refactor. |
|
361 | 370 | |
|
362 | 371 | * :mod:`Extensions` has been moved to :mod:`extensions` and all existing |
|
363 | 372 | extensions have been moved to either :mod:`IPython.quarantine` or |
|
364 | 373 | :mod:`IPython.deathrow`. :mod:`IPython.quarantine` contains modules that we |
|
365 | plan on keeping but that need to be updated. :mod:`IPython.deathrow` | |
|
366 |
|
|
|
367 |
|
|
|
368 | <module_reorg>`. | |
|
374 | plan on keeping but that need to be updated. :mod:`IPython.deathrow` contains | |
|
375 | modules that are either dead or that should be maintained as third party | |
|
376 | libraries. More details about this can be found :ref:`here <module_reorg>`. | |
|
369 | 377 | |
|
370 | 378 | * Previous IPython GUIs in :mod:`IPython.frontend` and :mod:`IPython.gui` are |
|
371 | 379 | likely broken, and have been removed to :mod:`IPython.deathrow` because of the |
|
372 | 380 | refactoring in the core. With proper updates, these should still work. |
|
373 | 381 | |
|
374 | 382 | |
|
375 | 383 | Known Regressions |
|
376 | 384 | ----------------- |
|
377 | 385 | |
|
378 |
We do our best to improve IPython, but there are some known regressions in 0.11 |
|
|
379 | to 0.10.2. | |
|
386 | We do our best to improve IPython, but there are some known regressions in 0.11 | |
|
387 | relative to 0.10.2. First of all, there are features that have yet to be | |
|
388 | ported to the new APIs, and in order to ensure that all of the installed code | |
|
389 | runs for our users, we have moved them to two separate directories in the | |
|
390 | source distribution, `quarantine` and `deathrow`. Finally, we have some other | |
|
391 | miscellaneous regressions that we hope to fix as soon as possible. We now | |
|
392 | describe all of these in more detail. | |
|
393 | ||
|
394 | Quarantine | |
|
395 | ~~~~~~~~~~ | |
|
396 | ||
|
397 | These are tools and extensions that we consider relatively easy to update to | |
|
398 | the new classes and APIs, but that we simply haven't had time for. Any user | |
|
399 | who is interested in one of these is encouraged to help us by porting it and | |
|
400 | submitting a pull request on our `development site`_. | |
|
401 | ||
|
402 | .. _development site:: http://github.com/ipython/ipython | |
|
403 | ||
|
404 | Currently, the quarantine directory contains:: | |
|
405 | ||
|
406 | clearcmd.py ipy_fsops.py ipy_signals.py | |
|
407 | envpersist.py ipy_gnuglobal.py ipy_synchronize_with.py | |
|
408 | ext_rescapture.py ipy_greedycompleter.py ipy_system_conf.py | |
|
409 | InterpreterExec.py ipy_jot.py ipy_which.py | |
|
410 | ipy_app_completers.py ipy_lookfor.py ipy_winpdb.py | |
|
411 | ipy_autoreload.py ipy_profile_doctest.py ipy_workdir.py | |
|
412 | ipy_completers.py ipy_pydb.py jobctrl.py | |
|
413 | ipy_editors.py ipy_rehashdir.py ledit.py | |
|
414 | ipy_exportdb.py ipy_render.py pspersistence.py | |
|
415 | ipy_extutil.py ipy_server.py win32clip.py | |
|
416 | ||
|
417 | Deathrow | |
|
418 | ~~~~~~~~ | |
|
419 | ||
|
420 | These packages may be harder to update or make most sense as third-party | |
|
421 | libraries. Some of them are completely obsolete and have been already replaced | |
|
422 | by better functionality (we simply haven't had the time to carefully weed them | |
|
423 | out so they are kept here for now). Others simply require fixes to code that | |
|
424 | the current core team may not be familiar with. If a tool you were used to is | |
|
425 | included here, we encourage you to contact the dev list and we can discuss | |
|
426 | whether it makes sense to keep it in IPython (if it can be maintained). | |
|
427 | ||
|
428 | Currently, the deathrow directory contains:: | |
|
429 | ||
|
430 | astyle.py ipy_defaults.py ipy_vimserver.py | |
|
431 | dtutils.py ipy_kitcfg.py numeric_formats.py | |
|
432 | Gnuplot2.py ipy_legacy.py numutils.py | |
|
433 | GnuplotInteractive.py ipy_p4.py outputtrap.py | |
|
434 | GnuplotRuntime.py ipy_profile_none.py PhysicalQInput.py | |
|
435 | ibrowse.py ipy_profile_numpy.py PhysicalQInteractive.py | |
|
436 | igrid.py ipy_profile_scipy.py quitter.py* | |
|
437 | ipipe.py ipy_profile_sh.py scitedirector.py | |
|
438 | iplib.py ipy_profile_zope.py Shell.py | |
|
439 | ipy_constants.py ipy_traits_completer.py twshell.py | |
|
440 | ||
|
441 | ||
|
442 | Other | |
|
443 | ~~~~~ | |
|
444 | ||
|
445 | * The machinery that adds functionality to the 'sh' profile for using IPython | |
|
446 | as your system shell has not been updated to use the new APIs. As a result, | |
|
447 | only the aesthetic (prompt) changes are still implemented. We intend to fix | |
|
448 | this by 0.12. | |
|
449 | ||
|
450 | * The installation of scripts on Windows was broken without setuptools, so we | |
|
451 | now depend on setuptools on Windows. We hope to fix setuptools-less | |
|
452 | installation, and then remove the setuptools dependency. | |
|
453 | ||
|
454 | ||
|
455 | Removed Features | |
|
456 | ---------------- | |
|
457 | ||
|
458 | As part of the updating of IPython, we have removed a few features for the | |
|
459 | purpsoes of cleaning up the codebase and interfaces. These removals are | |
|
460 | permanent, but for any item listed below, equivalent functionality is | |
|
461 | available. | |
|
462 | ||
|
463 | * The magics Exit and Quit have been dropped as ways to exit IPython. Instead, | |
|
464 | the lowercase forms of both work either as a bare name (``exit``) or a | |
|
465 | function call (``exit()``). You can assign these to other names using | |
|
466 | exec_lines in the config file. | |
|
380 | 467 | |
|
381 | * The machinery that adds functionality to the 'sh' profile for using IPython as your | |
|
382 | system shell has not been updated to use the new APIs. As a result, only the aesthetic | |
|
383 | (prompt) changes are still implemented. We intend to fix this by 0.12. | |
|
384 | 468 | |
|
385 | * The installation of scripts on Windows was broken without setuptools, so we now | |
|
386 | depend on setuptools on Windows. We hope to fix setuptools-less installation, | |
|
387 | and then remove the setuptools dependency. | |
|
469 | .. credits_:: | |
|
470 | ||
|
471 | Credits | |
|
472 | ------- | |
|
473 | ||
|
474 | Many users and developers contributed code, features, bug reports and ideas to | |
|
475 | this release. Please do not hesitate in contacting us if we've failed to | |
|
476 | acknowledge your contribution here. In particular, for this release we have | |
|
477 | contribution from the following people, a mix of new and regular names (in | |
|
478 | alphabetical order by first name): | |
|
479 | ||
|
480 | * Aenugu Sai Kiran Reddy <saikrn08-at-gmail.com> | |
|
481 | * andy wilson <wilson.andrew.j+github-at-gmail.com> | |
|
482 | * Antonio Cuni <antocuni> | |
|
483 | * Barry Wark <barrywark-at-gmail.com> | |
|
484 | * Beetoju Anuradha <anu.beethoju-at-gmail.com> | |
|
485 | * Benjamin Ragan-Kelley <minrk-at-Mercury.local> | |
|
486 | * Brad Reisfeld | |
|
487 | * Brian E. Granger <ellisonbg-at-gmail.com> | |
|
488 | * Christoph Gohlke <cgohlke-at-uci.edu> | |
|
489 | * Cody Precord | |
|
490 | * dan.milstein | |
|
491 | * Darren Dale <dsdale24-at-gmail.com> | |
|
492 | * Dav Clark <davclark-at-berkeley.edu> | |
|
493 | * David Warde-Farley <wardefar-at-iro.umontreal.ca> | |
|
494 | * epatters <ejpatters-at-gmail.com> | |
|
495 | * epatters <epatters-at-caltech.edu> | |
|
496 | * epatters <epatters-at-enthought.com> | |
|
497 | * Eric Firing <efiring-at-hawaii.edu> | |
|
498 | * Erik Tollerud <erik.tollerud-at-gmail.com> | |
|
499 | * Evan Patterson <epatters-at-enthought.com> | |
|
500 | * Fernando Perez <Fernando.Perez-at-berkeley.edu> | |
|
501 | * Gael Varoquaux <gael.varoquaux-at-normalesup.org> | |
|
502 | * Gerardo <muzgash-at-Muzpelheim> | |
|
503 | * Jason Grout <jason.grout-at-drake.edu> | |
|
504 | * John Hunter <jdh2358-at-gmail.com> | |
|
505 | * Jens Hedegaard Nielsen <jenshnielsen-at-gmail.com> | |
|
506 | * Johann Cohen-Tanugi <johann.cohentanugi-at-gmail.com> | |
|
507 | * Jörgen Stenarson <jorgen.stenarson-at-bostream.nu> | |
|
508 | * Justin Riley <justin.t.riley-at-gmail.com> | |
|
509 | * Kiorky | |
|
510 | * Laurent Dufrechou <laurent.dufrechou-at-gmail.com> | |
|
511 | * Luis Pedro Coelho <lpc-at-cmu.edu> | |
|
512 | * Mani chandra <mchandra-at-iitk.ac.in> | |
|
513 | * Mark E. Smith | |
|
514 | * Mark Voorhies <mark.voorhies-at-ucsf.edu> | |
|
515 | * Martin Spacek <git-at-mspacek.mm.st> | |
|
516 | * Michael Droettboom <mdroe-at-stsci.edu> | |
|
517 | * MinRK <benjaminrk-at-gmail.com> | |
|
518 | * muzuiget <muzuiget-at-gmail.com> | |
|
519 | * Nick Tarleton <nick-at-quixey.com> | |
|
520 | * Nicolas Rougier <Nicolas.rougier-at-inria.fr> | |
|
521 | * Omar Andres Zapata Mesa <andresete.chaos-at-gmail.com> | |
|
522 | * Paul Ivanov <pivanov314-at-gmail.com> | |
|
523 | * Pauli Virtanen <pauli.virtanen-at-iki.fi> | |
|
524 | * Prabhu Ramachandran | |
|
525 | * Ramana <sramana9-at-gmail.com> | |
|
526 | * Robert Kern <robert.kern-at-gmail.com> | |
|
527 | * Sathesh Chandra <satheshchandra88-at-gmail.com> | |
|
528 | * Satrajit Ghosh <satra-at-mit.edu> | |
|
529 | * Sebastian Busch | |
|
530 | * Stefan van der Walt <bzr-at-mentat.za.net> | |
|
531 | * Stephan Peijnik <debian-at-sp.or.at> | |
|
532 | * Steven Bethard | |
|
533 | * Thomas Kluyver <takowl-at-gmail.com> | |
|
534 | * Thomas Spura <tomspur-at-fedoraproject.org> | |
|
535 | * Tom Fetherston <tfetherston-at-aol.com> | |
|
536 | * Tom MacWright | |
|
537 | * tzanko | |
|
538 | * vankayala sowjanya <hai.sowjanya-at-gmail.com> | |
|
539 | * Vivian De Smedt <vds2212-at-VIVIAN> | |
|
540 | * Ville M. Vainio <vivainio-at-gmail.com> | |
|
541 | * Vishal Vatsa <vishal.vatsa-at-gmail.com> | |
|
542 | * Vishnu S G <sgvishnu777-at-gmail.com> | |
|
543 | * Walter Doerwald <walter-at-livinglogic.de> | |
|
544 | ||
|
545 | .. note:: | |
|
388 | 546 | |
|
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. | |
|
547 | This list was generated with the output of | |
|
548 | ``git log dev-0.11 HEAD --format='* %aN <%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u`` | |
|
549 | after some cleanup. If you should be on this list, please add yourself. |
General Comments 0
You need to be logged in to leave comments.
Login now