[IPython-dev] How to handle extensions

Brian Granger ellisonbg.net@gmail....
Fri Oct 9 18:00:20 CDT 2009


Robert,

Can you have a look at this branch and let me know how it looks:

https://code.launchpad.net/~ipython-dev/ipython/new-extensions

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.

Cheers,

Brian

On Fri, Oct 9, 2009 at 1:56 PM, Brian Granger <ellisonbg.net@gmail.com>wrote:

>
>
> On Fri, Oct 9, 2009 at 11:55 AM, Robert Kern <robert.kern@gmail.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
>> 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
> number of
> choices for loading the extension:
>
> get_ipython().load_extension('package.myextension')
>
> or
>
> %load_ext package.myextension
>
>
>> 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.
>>
>>
> 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
> right?
> 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
> extension,
> it is because they are using numpy (so importing it at startup would happen
> anyways).
>
> If a user didn't want to *always* have the numpy extension loaded, they
> could
> 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
>> from
>> 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
> launchpad,
> similar to this for Twisted related projects:
>
> https://launchpad.net/tx
>
> That way the development of all the extensions/profiles can proceed
> independently.
> I could even imagine that other things might eventually be moved outside
> the core
> to a place like this (GUI frontends, etc.)
>
> Cheers,
>
> Brian
>
>
>>
>> --
>> 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
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20091009/9f4b90be/attachment-0001.html 


More information about the IPython-dev mailing list