[IPython-dev] History
MinRK
benjaminrk at gmail.com
Thu Feb 17 14:31:38 EST 2011
Hi,
I like this idea. It's a bit unfortunate that we are starting this
discussion while Brian and Fernando are at conferences for a week, but we
have good ideas when we have them. It's possible there will be an objection
based on ideas of non-Python interfaces, but I think those are generally
implemented via history_request messages, which would still work and thus
not be a problem.
On Thu, Feb 17, 2011 at 10:46, Thomas Kluyver <takowl at gmail.com> wrote:
> 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.
>>
>
I don't think there's any real penalty to storing both (other than doubling
the size of a very small file), so might as well.
>
>
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.
>
I think the question here might be: what would the history look like at
startup if I've been running several sessions simultaneously, and I start a
new one?
<start IP0,IP1,IP2>
IP0: foo='bar'
IP1: a=1
IP2: b=2
IP1: c=3
<close IP0>
IP2: d=4
<start IP3>
i.e. what is the 'previous' session? Is it 'most recently closed' or 'most
recently started' or 'most recently executed'? You seemed to suggest above
that IP3's readline history at startup should go d,c,b,a,foo (as I continue
to press up) Is that correct? I like this approach, but there's also value
in keeping related commands (same session) adjacent to each other, so I
don't think it's an obvious choice. In most real cases, this probably
doesn't
make much difference.
>
> 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?
>
I would think a default should be something like 500 at the very least. I
use ctrl-r all the time, and basically expect that if I remember typing it,
IPython should remember as well. If you are just using arrow-keys, then
more than a few dozen isn't particularly valuable, but reverse-i-search
should find anything I remember well enough to look for.
-MinRK
>
>
>> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110217/ed9ca518/attachment.html>
More information about the IPython-dev
mailing list