[IPython-dev] Extensions: decisions on loading them and API (thoughts from R. Kern's branch)

Fernando Perez fperez.net at gmail.com
Sat Mar 14 20:27:00 EDT 2009

Hi all,

I was reviewing Robert's branch


which reminded me of revisiting our Extensions setup. That space has,
over time, gotten somewhat disorganized:

maqroll[Extensions]> ls *py
astyle.py                 ipy_foo.py              ipy_signals.py
clearcmd.py               ipy_fsops.py            ipy_stock_completers.py
envpersist.py             ipy_gnuglobal.py        ipy_synchronize_with.py
ext_rescapture.py         ipy_greedycompleter.py  ipy_system_conf.py
ibrowse.py                ipy_jot.py              ipy_traits_completer.py
igrid.py                  ipy_kitcfg.py           ipy_vimserver.py
__init__.py               ipy_legacy.py           ipy_which.py
InterpreterExec.py        ipy_lookfor.py          ipy_winpdb.py
InterpreterPasteInput.py  ipy_p4.py               ipy_workdir.py
ipipe.py                  ipy_profile_doctest.py  jobctrl.py
ipy_app_completers.py     ipy_profile_none.py     ledit.py
ipy_autoreload.py         ipy_profile_numpy.py    numeric_formats.py
ipy_bzr.py                ipy_profile_scipy.py    PhysicalQInput.py
ipy_completers.py         ipy_profile_sh.py       PhysicalQInteractive.py
ipy_constants.py          ipy_profile_zope.py     pickleshare.py*
ipy_defaults.py           ipy_pydb.py             pspersistence.py
ipy_editors.py            ipy_rehashdir.py        scitedirector.py
ipy_exportdb.py           ipy_render.py           win32clip.py
ipy_extutil.py            ipy_server.py

The two key things we need to do, probably right after the 0.10 release:

1. Stop putting Extensions into sys.path.  This is just bad practice,
as it pollutes people's import path with our stuff.  Users who want an
extension can just write

from IPython.Extensions import foo

instead of

import foo (or even ipy_foo)

it's not that much more work, and much, much cleaner.

2. Have all extensions require an explicit entry point to be
activated.  Something like

from IPython.Extensions import foo
foo.activate()  # this could take parameters, if the extension file
provides more than one thing.

I'm open to suggestions on this point, API ideas, etc.  But I have no
doubt that the current practice of extensions automatically
registering themselves with top-level code is a bad idea.  It means
that their mere import has side effects, which goes counter to most
standard python practice and can cause problems.  For example, things
like sphinx that import all modules can be badly messed up if each
extension starts having global side effects.

Ideally, extensions could also be unloaded, so perhaps the api should
read instead


for those that support it.  This would make the job of testing them
much, much easier.

Thoughts on the API, etc?  If we can agree on this, then at least
Robert's current one could already be fixed for this mode of use
before it sees public life.

More information about the IPython-dev mailing list