[IPython-dev] How to handle extensions
Fri Oct 9 18:00:20 CDT 2009
Can you have a look at this branch and let me know how it looks:
I have ported the pretty extension to the new api and moved it back into
extensions. It is not quite done, but I have to run out for a while. I
have changed the extension
API a bit to make this easier.
Let me know what you think.
On Fri, Oct 9, 2009 at 1:56 PM, Brian Granger <firstname.lastname@example.org>wrote:
> 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
> things now...
>> 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
>> 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
> field of the extensions that should be loaded at startup. Then you have a
> number of
> choices for loading the extension:
> %load_ext package.myextension
>> 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,
> let's pretend
> 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
> when the
> 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
>> without needing to import numpy itself to activate it in the
> 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 core
> 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