[IPython-dev] How to handle extensions

[Robert Kern]

On 2009-10-09 13:00 PM, Brian Granger wrote:

> * To be in IPython.extensions or IPython.config.profile a module has to
> satisfy a few things:
>
> - There has to be willingness amongst the core IPython developers to
> maintain the code.
> - The code needs to be reviewed (tests, docs, etc.)
> - If the code should be in IPython.core, it shouldn't be in extensions.
> - If an extension/profile can be distributed as a third party package,
> it should be.  Thus,
> the custom completer for enthough.traits should ship with
> enthought.traits.  Things related
> to numpy should ship with numpy.

There is one issue with this. You want to be able to configure some things for a 
particular package in your configuration files at startup, but not actually 
import the package, which may be expensive. With care, many of the 
package-specific extensions can be written in such a way as to be enabled at 
startup but not import the package until it absolutely must (in which case the 
user has probably already imported it himself). For example, I submitted a patch 
to ipy_traits_completer that replace isinstance(obj, HasTraits) checks for one 
that looked for superclasses named "HasTraits" before import HasTraits and doing 
the real isinstance() check.

Now, it wouldn't be too oppressive to put ipy_traits_completer into 
enthought.traits because we keep the __init__s clear (except for namespace 
package stuff, natch). But one couldn't put IPython support code into numpy 
without needing to import numpy itself to activate it in the configuration.

It might be worth having an ipy_extensions package distributed separately from 
IPython that collects these extensions to reduce the burden on the IPython 
developers and the quality disparity with the rest of code.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco