[IPython-dev] IPython.Extensions on sys.path

Walter Dörwald walter at livinglogic.de
Thu Nov 2 03:00:29 EST 2006

Ville M. Vainio wrote:

> On 11/1/06, Walter Dörwald <walter at livinglogic.de> wrote:
>> Is there a reason why IPython.Extensions is added? Could we drop this in
>> the next IPython release?
> There is a reason - it makes the modules in the directory easy to
> import (import bah instead of from IPython.Extensions import bah), and
> we can ship modules there that could also be available as third party
> modules (e.g. 'path'). That way, the same code can be used in and out
> of ipython (instead of having to type "from IPython.Extensions.path
> import path' or even 'from IPython.path import path', which would be
> invalid if IPython was not installed).

IMHO the proper way to treat such dependencies would be to document the 
dependency and let the user install the required module. With setuptools 
this can be done automatically:
            "path.py >= 2.1",

On Windows we already have a dependency on other packages (actually two: 
pyreadline and ctypes) anyway.

> A case in point - the "pickleshare" module just imports top level
> "path", and as such doesn't require IPython to be usable. The module
> is available outside IPython, and I didn't feel like "forking" a
> version for IPython (or trying to import path both from top level and
> IPython).

Would this mean that all modules that are just copies of third-party 
module and can work independently from IPython should be imported via 
"import foo" and modules that depend on IPython should be imported via 
"from IPython.Extensions import foo"?

> One alternative would perhaps be to declare all the stuff in
> Extensions as py_modules in setup.py. That way, at least with
> setuptools, they would be visible outside the IPython package as top
> level modules (yet still reside in the IPython egg directory).

I'm not sure. At least there would no longer be identical copies of the 
same module. But installing IPython would then "overwrite" the original 
version of the module, i.e. when importing it you'll get the IPython 
version instead of the original one.

> Is there really a problem, apart from the "path" module? If path is
> the only problem, we could add 'path' to 'py_modules' and remove it
> from Extensions. But the rest should IMHO stay as it is. Many modules
> in Extensions are unusable outside IPython anyway.

I'd like to use Philip Eby's simplegeneric module 
(http://cheeseshop.python.org/pypi/simplegeneric) for ipipe. xrepr(), 
xiter() and xattrs() could benefit from being generic functions. I 
already experimented in this direction some time ago, but now that a 
simple standalone generic function module is available it no longer 
makes sense to reinvent the wheel.

Philip's OK with us bundling the module, as long as it doesn't conflict 
with any installed version of simplegeneric, which it would (but only 
when running inside IPython).


More information about the IPython-dev mailing list