New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
History access #824
History access #824
Conversation
Hey Thomas, it looks like conflicts slipped in from recent merges. Could you rebase before we can have a look? Thx! |
Done, it was only one small conflict. |
output_hist_reprs = Dict() | ||
|
||
class HistoryAccessor(Configurable): | ||
"""Access the history database without adding to it. For use by standalone |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's try to keep, here and elsewhere, to the format for docstrings (just like git commit messages) of 'one line summary, blank line, more verbose description). Tooltips that use the one line summary look bad if it's broken up.
Otherwise looks good. It seems to be mostly refactoring, which means it should be pretty safe. But since I see there's a new method (for range), I'd like to see at least a test or two for that guy in isolation. The better we can make our test coverage... |
OK, I've tweaked that docstring. I don't think I've added any really new methods - HistoryAccessor has a |
No, what I meant is that now there's a bit of logic that's nicely isolated in the private I hope soon we'll start turning on test coverage reports in the test suite, so we can begin tracking our progress on that front. In the meantime, every little bit we can do will help. What do you think? |
Added some tests. |
Is this ready for merge? It sounds like review has been covered, assuming tests pass. |
As far as I know, it's ready to go. |
Okay, then I say go for it. I think writing some good examples for turning sessions into scripts etc. with the new Accessor would be great, since it's fairly easy, but not immediately obvious. |
Actually, just thinking about it, I'd like to add a slightly nicer interface to load history for a particular profile. Do we have a function that will get the folder (as in, |
We have ProfileDir objects for managing/creating/locating profile directories, so you can do: from IPython.core.profiledir import ProfileDir
pd = ProfileDir.find_profile_dir_by_name(get_ipython_dir(), 'foo')
path = pd.location Perhaps adding this to utils.path would be useful: def locate_profile(profile='default'):
from IPython.core.profiledir import ProfileDir, ProfileDirError
try:
pd = ProfileDir.find_profile_dir_by_name(get_ipython_dir(), profile)
except ProfileDirError:
# IOError makes more sense when people are expecting a path
raise IOError("Couldn't find profile %r" % profile)
return pd.location |
Thanks Min, that's just the ticket. |
OK, I've made the API improvement I wanted, added an example script ( |
Thanks! Yes, that would be great. All of the %log, etc. tools should probably use this as well. |
Magics like %hist, %macro, %save and so on already do. The %log* machinery writes cells directly to a text file. |
This separates out an
HistoryAccessor
class, which can be used to read the history db without initialising an IPython shell.HistoryManager
becomes a subclass of that, adding in the methods to write to the database.