[IPython-dev] Status of ipy_pretty and ipy_traits_completer?
Thu Oct 8 17:25:50 CDT 2009
On Thu, Oct 8, 2009 at 1:58 PM, Robert Kern <firstname.lastname@example.org> wrote:
> On 2009-10-08 15:42 PM, Brian Granger wrote:
> > Robert,
> > I agree it would be useful to have a README in those directories, but I
> > wasn't entirely
> > neglectful:
> > From the "changes/whatsnew" docs:
> > From module_reorg:
> I read those. I asked because those documents give a number of listed
> reasons a
> module could be in either directory. They don't tell me which reason you
> applied to each module. For example, ipy_traits_completer could plausibly
> be in
> deathrow because it didn't have a maintainer (my submitted patches
> notwithstanding) or because you thought it belonged in a separate package.
> appropriate next action depends on which reason you had in mind.
Ah, Yes, you are absolutely right, especially about the reasons something
may be in
deathrow. I sorted through the extension modules putting them into either
deathrow, simply because most (if not all) of them are currently broken
because of the API
changes that have been made. In many cases, I had no idea what the status
of various extensions
(are they used by anyone, were they broken before the API changes) was
and I made a very rough guess about where it should go (quarantine or
My *intention* is that when people see their favorite extension in
quarantine or deathrow,
that *have* to come to the list to help us figure out what needs to happen.
that is how we can figure out which extensions "matter" and which have
life or belong elsewhere.
For ipy_pretty and ipy_traits_completer it is easy, because I know what they
do and that they are
still used. But for many other ones, I personally have *no idea* what there
so it really needs to be discussed on list.
Summary: I want people to have to ask on list about the status of things in
> Based on this, I would say the following:
> > * ipy_pretty should be cleaned up,
> What needs to be cleaned up?
It needs to be converted to the new extension API. Here are the docs for
(this is in docs/source/config/ipython.txt)
A list of strings, each of which is an importable IPython extension. An
IPython extension is a regular Python module or package that has a
:func:`load_in_ipython(ip)` method. This method gets called when the
extension is loaded with the currently running
:class:`~IPython.core.iplib.InteractiveShell` as its only argument. You
can put your extensions anywhere they can be imported but we add the
:file:`extensions` subdirectory of the ipython directory to ``sys.path``
during extension loading, so you can put them there as well. Extensions
are not executed in the user's interactive namespace and they must
be pure Python code. Extensions are the recommended way of customizing
The easy part is this, if you remove the ipapi stuff and instead all the
following to the bottom:
ip.set_hook('result_display', pretty_result_display, priority=99)
The slightly more involved part is that the way the config variables are
need to be changed. I don't mind doing this as an example if you can wait
(my son's 4th B-day is today!). But, one question: once
the extension is activated, who does a user activate a custom displayer for
By calling for_type/for_type_by_name (which are injected into the userns)?
It would be great to convert this to the new API to show how it all works.
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> that is made terrible by our own mad attempt to interpret it as though it
> an underlying truth."
> -- Umberto Eco
> IPython-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev