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