[IPython-dev] History

Satrajit Ghosh satra at mit.edu
Thu Feb 17 14:36:59 EST 2011


hi thomas and hans,

just a few thoughts.

(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/
>

history is currently in json files and yes it does get long, but reading
json is now part of the standard library. we can definitely save space by
replacing identical commands between raw and processed with only one copy.
when fernando and i worked on this in december, we increased the save
history limit in the config.


>
>
>> 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.
>

we do have concurrent history as long as the clients connect to the same
kernel. this is in fact what we implemented between the qt client and the
terminal client or combinations thereof. but this will be different from
using separate kernels.


>
>  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?
>

are we really in memory trouble these days? or is this more a question of
load time?

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110217/ca28df88/attachment.html>


More information about the IPython-dev mailing list