Slightly over a month ago we released IPython 6.0 : the first version of IPython to be compatible only with Python 3. The reception of IPython 6.0 was great, and the codebase way more maintainable. So while 6.0 was mostly focused on internal refactoring and working upstream to make the release of a Python 3 only version possible, the next releases can focus on bug fixes and new features. Today we not only have the new release of IPython 6.1, but IPython 5.4 as well (the LTS branch targeting Python 2.7). Read on for more information! As usual, you can upgrade using pip and the 🔥 Conda Forge 🔥 builder is warming up: IPython 5.4, and 6.1 should be available via these channels soon.
IPython 5.4 (and 6.1) major new features
IPython 5.x is the LTS branch which is still compatible with Python 2. The IPython team ♥️ Python 2 users so we continue to make fixes to our 5.x branch. You can install it today by making sure you have pip 9 or above:
$ pip --version pip 9.0.1
Then upgrade IPython:
$ pip install ipython --upgrade
If you do not have pip 9 and are using Python 2, pip may download IPython 6, which will not work on your system. If you are on Python 3, see the next section to upgrade to IPython 6.1 but read on in this section for the new features.
IPython 5.4 got a number of new features that went into 6.0, plus a number of API improvements from 6.1 allowing the underlying library to target both 5.4+ (Python 2+3) and 6.1+ (Python 3) without having conditional branches. This should make the transition easier for users and developers
You can see the what’s new for:
In 6.0 and 5.4 IPython gained a new
c.TerminalIPythonApp.interactive_shell_class option, to customize the class used to start the terminal frontend. This should enable you to use custom interfaces, such as reviving the former readline interface which is now a separate package. See the next section for more.
In IPython 6.1+ and 5.4+ object can now define
_repr_mimebundle_ in place of multiple
_repr_*_ methods and return a dictionary of MIME types and MIME data for rich display. IPython provides
_ipython_display_ but this mechanism was complex and difficult to use for frontends with different architectures, such as nteract and hydrogen. This new
_repr_mimebundlde_ methods are thus simpler for both backend and frontends developers to implement, and are already handled in projects like nteract. Our own JupyterLab, the next-generation evolution of the Jupyter Notebook, takes full advantage of these capabilities to expose rich and flexible data display capabilities that work not only in notebook documents, but across all of JupyterLab.
This new model will simplify things for client implementations and will facilitate the publication of custom mimetypes (GeoJson, Plotly, DataFrames, etc.). See the
Custom Display Logic example notebook for examples and technical details.
In IPython 5.4+ and 6.1 +, the heuristic for execution in the command line interface is now more biased toward executing for single statement. Use
Ctrl-O to force the insertion of a new line. The execution semantics of
Enter were still debated, so if you like to configure that you can define your own function which decides what to do.
IPython 5.4 and 6.1+ implement display ids, which can be used to update a displayed object. This should provide simple patterns to implement common cases of dynamic display updates (see
Updating Displays.ipynb notebook). It will also simplify the implementation of some types of interactive user interface elements, such as progress-bars. Display objects with IDs can be updated from other cells or frontends.
The display function is now always available
display() function is now available by default in the IPython session, without users having to import anything.
display() is the "moral equivalent” of
print(), but takes advantage of the rich display capabilities of Jupyter (and defaults to printing a string for objects lacking rich representations). By making
display() appear, in practice, as if it was built-in, we hope to encourage library authors to provide their objects with rich and informative representations that users can now more conveniently access, whether at the IPython REPL or in any of the richer clients in the Jupyter ecosystem (JupyterLab, classic Notebook, nteract, etc.). Note that this automatic import of
display() is only done in the live IPython kernel; scripts and libraries that rely on display and may be run outside of IPython still need to import it using
from IPython.display import display.
Many users were pleased with the transition from readline to
prompt_toolkit for IPython 5.0, this gave IPython multiline editing, nice completion and highlighting as you type. Still some users are missing the old readline interface (for its reactiveness an custom keybindings) though are still using IPython 4.x series.
While prompt toolkit is still the default interface, you can now use the new configuration option
c.TerminalIPythonApp.interactive_shell_class .With this you can now replace the Prompt_Toolkit interface. For one of your liking.
Rlipython is one of these alternative interface that resurect readline and is lighter, and more responsive on some system than default IPython. Using it still give you most of the new features of IPython 5.x or 6.x ! This should also please many of our users who use vi keybinding in terminals as this should respect
To try rlipython, install it with pip,
$ pip install rlipython
And follow the instructions.
We look forward to your contribution and please give lots of 💖 by to @ivanov (tweet) for making this possible.
IPython 6.1 and Python 3 only features
IPython 6.1 is the first minor release of our Python 3 only branch, it is the branch that get the most work, and start to use great new features such as type annotations, async/await [more to be added]. You can install it today please upgrade pip to pip 9 if you can, then upgrade IPython:
$ pip install ipython --upgrade
You’ll get all the new features in 5.4, some of which are already in IPython 6.0, plus a number of additional enhancements:
You can read more on the what’s new for IPython 6 what’s new.
In this release, we had a number of bug fixes and improvements from developers at TwoSigma, who participated in an internal open-source hackathon for Jupyter/IPython in May. Hackathon attendees tackled some long standing, hard to debug issues, and feature requests. Among these:
- Quotes in a filename are always escaped during tab-completion on non-Windows, which should make many of our windows users happy. As none of the core devs use windows this one needed someone to simply use some elbow grease!
- Variables now shadow magics in autocompletion which make autocompletion of things like
matplotlibsimpler and less surprising. - Magic aliases can now have parameters.
pinfo2machinery will show docstrings if source can’t be retrieved.
The completer also got a number of small improvements, and is smarter in many cases. For example, it understands the arguments to the
%colors magics. Long methods and
snake_case function names can now be completed from abbreviations. For example, if
foo_bar_kitten is an existing object,
f_b<tab> will find it as a possible completion.
Look out for a blog post from TwoSigma.
Only a small number of improvements are describe here, and we encourage you to read the full change logs if you want to know more.
We hope that all these releases will make you more productive. We welcome your contributions, and questions. Feel free to open issues on GitHub, we’ll do our best to respond.