[IPython-dev] How to handle extensions
Fri Oct 9 13:55:40 CDT 2009
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.
"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
More information about the IPython-dev