[IPython-user] IPython1 0.3 prerelease
Mon May 12 22:05:55 CDT 2008
We are getting ready to release version 0.3 of IPython1. This version
has been long in the waiting and has lots of new features and
enhancement. Trying IPython1 out is easier than ever, as it is
easy_installable now (don't worry, we still have a plain distutils
setup.py as well):
This will get the latest ipython1 0.3 prerelease as well as Twisted
and zope.interface if you don't have it. Please try installing this
prerelease and running the test suite (trial ipython1). The final
version of ipython1 0.3 will be cut later this week.
For the curious, here are the list of changes:
* Much improved ``setup.py`` and ``setupegg.py`` scripts. Because Twisted
and zope.interface are now easy installable, we can declare them as
in our setupegg.py script.
* IPython1 is now compatible with Twisted 2.5.0 and 8.x.
* Added a new example of how to use :mod:`ipython1.kernel.asynclient`.
* Initial draft of a process daemon in :mod:`ipython1.daemon`.
* The ``TaskController`` now has methods for getting the queue status.
* The ``TaskResult`` objects not have information about how long the task
took to run.
* We are attaching additional attributes to exceptions ``(_ipython_*)`` that
we use to carry additional info around.
* New top-level module :mod:`asynclient` that has asynchronous versions (that
return deferreds) of the client classes. This is designed to users who want
to run their own Twisted reactor
* All the clients in :mod:`client` are now based on Twisted. This is done by
running the Twisted reactor in a separate thread and using the
:func:`blockingCallFromThread` function that is in recent versions
* Functions can now be pushed/pulled to/from engines using
* Gather/scatter are now implemented in the client to reduce the work load
of the controller and improve performance.
* Complete rewrite of the IPython1 docuementation. All of the documentation
from the IPython1 website has been moved into docs/source as restructured
text documents. PDF and HTML documentation are being generated using
* New developer oriented documentation: development guidelines and roadmap.
* Traditional ``ChangeLog`` has been changed to a more useful
that is organized by release and is meant to provide something more relevant
* Created a proper ``MANIFEST.in`` file to create source distributions.
* Fixed a bug in the ``MultiEngine`` interface. Previously, multi-engine
actions were being collected with a :class:`DeferredList` with
``fireononeerrback=1``. This meant that methods were returning
before all engines had given their results. This was causing extremely odd
bugs in certain cases. To fix this problem, we have 1) set
``fireononeerrback=0`` to make sure all results (or exceptions) are in
before returning and 2) introduced a :exc:`CompositeError` exception
that wraps all of the engine exceptions. This is a huge change as it means
that users will have to catch :exc:`CompositeError` rather than the actual
Backwards incompatible changes
* All names have been renamed to conform to the lowercase_with_underscore
convention. This will require users to change references to all names like
``queueStatus`` to ``queue_status``.
* Previously, methods like :meth:`MultiEngineClient.push` and
:meth:`MultiEngineClient.push` used ``*args`` and ``**kwargs``. This was
becoming a problem as we weren't able to introduce new keyword arguments into
the API. Now these methods simple take a dict or sequence. This
has also allowed
us to get rid of the ``*All`` methods like :meth:`pushAll` and
These things are now handled with the ``targets`` keyword argument
* The :attr:`MultiEngineClient.magicTargets` has been renamed to
* All methods in the MultiEngine interface now accept the optional
* Renamed :class:`RemoteController` to :class:`MultiEngineClient` and
:class:`TaskController` to :class:`TaskClient`.
* Renamed the top-level module from :mod:`api` to :mod:`client`.
* Most methods in the multiengine interface now raise a
that wraps the user's exceptions, rather than just raising the raw
* Changed the ``setupNS`` and ``resultNames`` in the ``Task`` class
More information about the IPython-user