Skip to content
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

Clarification of history_request status and future plans #976

Open
krassowski opened this issue Oct 3, 2023 · 1 comment
Open

Clarification of history_request status and future plans #976

krassowski opened this issue Oct 3, 2023 · 1 comment

Comments

@krassowski
Copy link
Member

krassowski commented Oct 3, 2023

history_request is currently described as not in use in the main notebook interface and says that some options may be removed in the future (in a note added 7 years ago).

Most of the history messaging options are not used by Jupyter frontends, and
many kernels do not implement them. If you're implementing these messages in
a kernel, the 'tail' request is the most useful; this is used by the Qt
console, for example. The notebook interface does not use history messages
at all.
This interface was designed by exposing all the main options of IPython's
history interface. We may remove some options in a future version of the
message spec.

While the above is true as of today, two pull request against JupyterLab propose exposing the history information in the notebook interface (which will likely propagate to Jupyter Notebook v7.x) as opt-in features:

The former uses the same request as presently implemented in JupyterLab console:

{
  output: false,
  raw: true,
  hist_access_type: 'tail',
  n: 500
}

and the latter makes use of search function:

{
  output: false,
  raw: true,
  hist_access_type: 'search',
  pattern: linePrefix + '*',
  unique: true,
  n: this._maxSuggestions
}

Aside: I find the pattern option specification a bit unclear e.g. whether there are escaping characters which would allow to escape . and * wildcards.

Once these pull requests are merged and released, the history request API will gain more prominence and more kernels will want to implement it. It might be then harder to change the APIs.

  1. Which options were planned for removal? Should those be deprecated? Are those any of options proposed in the pull requests mentioned above?
  2. Are there any other changes/addition that we want to expose out of IPython?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant