[IPython-dev] History

[Thomas Kluyver]

On 17 February 2011 17:53, Hans Meine <hans_meine at gmx.net> wrote:

> +0.9
> (it will become a little bit harder to directly access the history,
> compared
> to the plain text files at least)
>

True, but I don't think that's a common use case (correct me if I'm wrong).
And there are tools to access SQLite databases if you need to, e.g.
http://sqlitebrowser.sourceforge.net/

 Why "completed"?  I would assume that a crashing command will still appear
> in
> the DB?!
>

My mistake. For some reason, I thought that input was stored in history
after execution. Checking the code, it's stored before, so a crashing
command would be saved. That should have been obvious.

 Not sure about this one - sounds fragile, I guess there was a reason to
> store
> the processed commands; what about processing which depends on currently
> active aliases etc.?  My fear is that this will become difficult to
> recompute.


> OTOH, most of the time, the two commands are absolutely equal.  What about
> two
> DB columns, but leaving the processed command empty if it is equal to the
> raw
> command?  This could save a lot of space, and it would be trivial to create
> a
> view which provides the two full columns.
>

Good point, I hadn't thought of temporary aliases (I've never used them);
and good solution. While we're on the subject, what does translation
actually do? %magic commands, !system commands, aliases; anything else?


> I would still expect only local commands to appear in the normal readline
> history, and in the default %history output.  IMO there should be optional
> modes (something along %history --all) which list the other shells'
> history.
>

Yes, that's what I'd envisage. At present, %history -g is used for a glob
search over all the history; passing it no pattern is the way to list
history from all sessions.

The readline history wouldn't be updated from other sessions - so commands
you enter in shell 1 before starting shell 2 will be loaded into readline
for shell 2, but then only shell 2 commands would be added to that. Starting
a third shell would not add anything to readline in shell 2.

 Hmm, what about concurrent sessions?  (Versus "previous" sessions which
> have
> been quit.)
>

Interesting idea, but more complicated to implement. You'd have to somehow
have separate shells signal their presence. I think this is a separate
consideration - I'm looking at what we can get for free by restructuring the
history.

 Are you kidding me?  One session equals roughly 1400 lines for me. :-)
>
> That's a good question, how much history should be available from
> "previous"
> sessions.
>

But how much of that do you access through readline? It can of course be
user configurable, but we should set a sensible default. 40 is on the low
side. I assume readline is fairly fast: maybe a couple of hundred is a good
limit?


> You wrote "will be able to access commands entered in the other session as
> soon as they are completed" - does this require ipython to constantly read
> from the DB?  No, obviously there should be a history API that directly
> operates on the database.
>

Sorry, I should have been clearer about what I meant by access. Those
commands will be in the database immediately, and accessible with magic
commands (e.g. "%rep -1#9" or "%hist -g"), which will call the history API
to read the database. Other than those commands, IPython would only read the
database on startup, to push lines into readline.

Thanks for the feedback,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110217/e4a9bcfd/attachment.html>