[IPython-dev] How to handle extensions
Fri Oct 9 15:56:09 CDT 2009
On Fri, Oct 9, 2009 at 11:55 AM, Robert Kern <email@example.com> wrote:
> 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.
This is an important point and I want to understand the issues and fix
> 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 the changes I have in my local branch this is possible. You simply
enter the config
information in the config files, but don't list the extensions in the config
field of the extensions that should be loaded at startup. Then you have a
choices for loading the extension:
> With care, many of the
> package-specific extensions can be written in such a way as to be enabled
> startup but not import the package until it absolutely must (in which case
> user has probably already imported it himself). For example, I submitted a
> to ipy_traits_completer that replace isinstance(obj, HasTraits) checks for
> that looked for superclasses named "HasTraits" before import HasTraits and
> the real isinstance() check.
The question of a lazy loading of an extension is a good point. For now,
that an extension can be imported/loaded without any side effects (it is not
in a package
that has an __init__ that imports everything). Then lazy importing is easy
You can just make sure that the package (traits/numpy/etc) isn't imported
extension is imported, but later, when the extension is first used.
But don't you think that if someone has explicitly enabled a numpy based
it is because they are using numpy (so importing it at startup would happen
If a user didn't want to *always* have the numpy extension loaded, they
simple maintain a numpy profile that loaded numpy.
But if you really need lazy importing, I think it is possible still...
> 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.
Yes, for packages that have lots of things in __init__, this is a problem.
For something as common as numpy, I think shipping it in IPython.extensions
may make sense.
> It might be worth having an ipy_extensions package distributed separately
> IPython that collects these extensions to reduce the burden on the IPython
> developers and the quality disparity with the rest of code.
This is a good point. I have envisioned something like a meta-project on
similar to this for Twisted related projects:
That way the development of all the extensions/profiles can proceed
I could even imagine that other things might eventually be moved outside the
to a place like this (GUI frontends, etc.)
> 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