[IPython-dev] RFC: IPython.ipapi for "public" ipython API.
Fernando.Perez at colorado.edu
Fri Jan 13 12:25:31 CST 2006
Ville Vainio wrote:
> It's not immediately obvious where the extension points for ipython
> are, so I figured we ought to have one module that user
> extensions/config files would use to plug into ipython.
> I'm of course thinking of
> import IPython.ipapi as ip
> ip.ipmagic("%alias ls ls -F")
The basic idea is correct, and I've been trying to slowly move in that
direction already, with more consistent names and calling interfaces (the ip*
There are a few things to note though:
- I don't think this can be done as a module: what ipython would those
functions talk to? Remember, in an embedded ipython situation, there can be
multiple ipython instances simultaneously active within one python process,
and those can even be nested within one another.
Embedded ipython does have its users (myself, for example :), so we need to be
careful about how this is implemented.
- Let's make sure that users are aware that some of this may change in the
chainsaw branch to some extent. We should try to make decent decisions now,
so the same code and API can carry forward to the new ipython, but in the new
branch clean design will win over backwards compatibility. In the current
branch, the priorities are inverted: any changes made in trunk/ should be
minimally disruptive to current users.
This page has some notes on extension issues:
I need to move the information in the new_design PDF from the docs into this
wiki, so we centralize and organize the results of all design discussions in a
clean public area.
Note that I don't think a wiki is a good place to _hold_ the discussion, for
that a mailing list is IMHO far better. But once a minimal idea has somewhat
solidified, noting it down on the wiki allows the process to move forward.
Things can still be changed, but the wiki becomes the record of the current
state of the issue, after the back-and-forth of the arguments on the list.
More information about the IPython-dev