IPython: Productive Interactive Computing

Description

Adds backbone.js layer on top of comm layer to enable the creation of modular widgets. See IPEP 23 for a detailed description.

Organization

• Widget manager /ipython/IPython/html/static/js/widgetmanager.js
• Javascript models and associated views /ipython/IPython/html/static/js/widgets/widget*.js
• Python widgets /ipython/IPython/html/widgets/widget*.py
• Unit tests /ipython/IPython/html/tests/casperjs/test_cases/widgets*.js
• Example and tutorial notebooks /ipython/examples/widgets/*.ipynb

Examples

Examples and tutorials are included in this PR's contents (as seen above) direct link

Included Widgets

• CheckboxWidget
• ToggleButtonWidget
• ButtonWidget
• ContainerWidget
• PopupWidget
• FloatSliderWidget
• BoundedFloatTextWidget
• FloatProgressWidget
• FloatTextWidget
• ImageWidget
• IntSliderWidget
• BoundedIntTextWidget
• IntProgressWidget
• IntTextWidget
• AccordionWidget
• TabWidget
• ToggleButtonsWidget
• RadioButtonsWidget
• DropdownWidget
• SelectWidget
• HTMLWidget
• LatexWidget
• TextareaWidget
• TextWidget

To try this out: pip install terminado, launch the notebook server, and go to http://localhost:8888/terminals/new (or replace new with any alphanumeric name).

You have an arbitrary number of named terminals. Tabs open to the same URL share a terminal - this isn't always flawlessly visually, especially if you open a new tab with something like vim already running, because it just sends the output, as it arrives, to all connected tabs, but it works pretty well in my informal tests.

If it can't load terminado, e.g. because you're on Windows, these handlers don't get added at all.

For now, terminals are only shut down if you quit your shell inside them. It should be easy, however, to build a REST API which can kill terminal sessions, and a UI on top of that.

I've copied the relatively minimal JS from terminado into our JS tree, because that seemed simpler than working out how to handle serving JS from another Python package. The big chunk of JS code, term.js, is added to the components submodule in a branch.

This is supposed to be a step to fix issue #7968. It allows to obtain the same current behavior without using Javascript and then it will be possible to fix #7701. However, more input is needed.

Sticky header when scrolling down:

Keeping the same margin between #header and #site elements when resizing window:

Small issue. If there are scrollbars, the width of the window is calculated differently. As a consequence, the media query is not activated as it should when the header's height is increased:

If the browser is shrunk a bit more, then the media query takes effect. Unfortunately, I don't think there is a clean solution for this. Removing the media queries could be an option to give a more consistent behavior although this reduces the margin between #header and #site in small windows.

/tree page is not affected by these changes because I added classes specific to /tree and /notebook.

@minrk is responsible for this, but I added this issue because @davclark expressed interest in improving the RMagic.

Be sure to extract (preserve) the git history for files related to the magic, and any documentation for it (such as example notebooks)

• [x] %%R magic (work by @davclark, @gmbecker and @lgautier)
• [x] %%Cython magic
• [x] %%octave magic (oct2py author @blink1073 is on this)

Still quite a bit to do, but the implemented parts of v4 are working pretty well. I did find and fix some things while testing the validation. Both v3 and v4 have a Draft 4 jsonschema, and use the standard jsonschema format for references, so jsonpointer is no longer used.

closes #5074

TODO in separate PRs:

• backport v4->v3 to 2.x
• what to do when uploading old notebooks (upgrade on upload, or leave alone and upgrade on open)?
• [x] add convert 3<->4
• [x] make v4 current
• [x] update stream messages to name, text
• [x] move display_data.png to display_data.data['image/png']
• [x] what's new
• [x] decide on UI for downgrade
• [x] upgrade existing example notebooks

The goal of this PR is to fix the various focus related problem in the notebook user experience. The issue for this is #3441. The source of the problem is that we used to call this.code_mirror.focus when a cell was selected. This caused all of the jumpy behavior. However, when this call was removed, the entire user experience fell apart. This PR is an attempt to restore a solid user experience while also removing the problematic focus calls.

The result is that the notebook is now a dual mode editor with a command mode and edit mode. Command mode is entered using ESC or Ctrl-m. Thus our old keyboard shortcuts still work, but multiple of them can be given after you type Ctrl-m. Edit mode is entered for the current cell by pressing Enter. This is not ready for merge, but we are thinking about trying to merge this for 1.0. But, it will need lots of testing. The code is relatively simple, but the new interaction model is quite subtle and there are numerous tweaks we could make.

Another side effect is that multiple markdown, rawtext and heading cells can now be unrendered at the same time.

Overall I think this is a massive improvement of the user experience. But, this needs tons of interactive hands on user experience testing.

Remaining issues:

• [ ] Test various notebook and cell actions (cut, copy, paste, merge, split, etc.).
• [ ] Keyboard shortcuts for command mode need to be turned off when the notebook area is not in focus. This is currently preventing dialogs and other things that require keyboard input from working.
• [ ] Test and debug tooltips.
• [ ] Test to make sure that the pager can be closed with ESC.
• [ ] Test and debug tab completion.
• [ ] Possibly refactor the keyboard shortcut code to make it all configurable.

Questions:

• Do we like how Shift-Enter, Ctrl-Enter and Alt-Enter behave?
• Should we always enter edit mode when a cell is changed type?
• Do people like the green border to indicate edit mode?
• Do we want to keep ESC for entering command mode?

IPEP 21 has full description of the proposal.

This is just the basic communication tube, through which widgets might communicate.

It's pretty basic, but it seems to work reasonably well.

Some example use cases for the Comms implemented here: http://nbviewer.ipython.org/6547109

This also refactors callbacks in a clearer way, allowing callback cleanup since widget messages dramatically exacerbate #2524.

closes #2524.

Should work in more environments than plain websockets.

Still some work to do, checking out authentication, etc., but the basics definitely work.

Third-party code added: sockjs-tornado (in IPython.external), sockjs-client (in static/sockjs).

This PR is functionally equivalent to #2382 but involves substantially less refactoring. Note, however, that ZMQ is now required.

The gist referenced in the previous PR contains usage examples: https://gist.github.com/3659874.

Update from @carreau : Reopening, tagging 5.4 we should vendor shutil_get_terminal_size.

After installing ipython sudo apt-get install ipython-notebook , ipython it appears a error, as follows:

jiangyuping@Lenovo:~$ ipython Traceback (most recent call last): File "/usr/local/bin/ipython", line 4, in from IPython import start_ipython File "/usr/local/lib/python2.7/dist-packages/IPython/init.py", line 48, in from .core.application import Application File "/usr/local/lib/python2.7/dist-packages/IPython/core/application.py", line 25, in from IPython.core import release, crashhandler File "/usr/local/lib/python2.7/dist-packages/IPython/core/crashhandler.py", line 28, in from IPython.core import ultratb File "/usr/local/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 128, in from IPython.utils.terminal import get_terminal_size File "/usr/local/lib/python2.7/dist-packages/IPython/utils/terminal.py", line 22, in from backports.shutil_get_terminal_size import get_terminal_size as _get_terminal_size ImportError: No module named shutil_get_terminal_size

This a prototype to edit metadata. right now you need to execute

To see the UI change.

I'll add a button to the toolbar to do so once #2127 is merged. looks like

Cell "header" are togglable by above command, and clicking on "raw edit" bring the modal editor.

My question is what kind of API do we want to add other buttons to the cell header/toolbar.

Obviously if an extension want to add a button, the button needs to be be added to all the current cell of a certain type.

Do we allows extension to be loaded at any time, or do we says that some stuff can only be extended if the extension is loded at notebook load time?

And we also need maybe an event to say that the metadata have changed.

Update :

see this comment To see how to enable.

Unfortunatly, as discussed here: https://github.com/ipython/ipython/issues/13815. The feature is not implemented correctly as the global wheel has the entrypoints hard-coded to the minor version of the python used to create them. This PR will remove that third entrypoint.

Side note: I didn't see any github acftion to publish new versions of the package. Will it be ok if I create a new PR with one and if so, would it be acceptible if I make it so the github action would run on all supported minor versions of python to create a wheel that is aware of the minor version (so the feature would be able to be re-implemented)?

IPython supports multi-line edits when its internal logic determines that the initial input line is not a valid standalone statement (e.g. ends with a colon or has unclosed parentheses). Once inside a multi-line edit, the only way to execute it is to go to the end of the line end press enter twice.

There are two features that could be independently useful:

1. Key binding (e.g. CTRL-ENTER) to execute multi-line input regardless of the location of the cursor. This is useful when one is editing a multi-line input and wants to execute it without navigating to the last line and pressing ENTER twice.
2. Key binding (e.g. SHIFT-ENTER) to force start a multi-line edit (even if the first line is a valid single-line statement).

What do you think?

Hi,

IPython recently introduced hinted suggestions as input is being typed. The user can accept the suggestion by pressing END or RIGHT. Alternatively, the user can scroll through other prefix matches in the history by pressing UP (and DOWN). However, all these modes of navigation move the cursor to the end of the line. It is impossible to accept a prefix of a hinted suggestion.

We would like to propose keeping the cursor in place and naturally supporting the cursor movement with the logic of “accept anything that is on the LHS of the cursor”. This would allow reusing long prefixes without the need to accept the entire line and make edits from its end.

For example, suppose the history includes very.long.module.foo.func() very.long.module.bar.Baz() The user types the prefix “very.”. The hinted suggestion would be “long.module.bar.Baz()”. The user can now press:

1. RIGHT/CTRL-RIGHT to accept letters/words from the hinted completion. This would make it easier to type “very.long.module.bar.Zap()”.
2. END to accept the entire suggestion.
3. UP to replace the hinted suggestion with “long.module.foo.func()” (cursor stays in place).
4. BACKSPACE to delete last character and resume hinting from the new prefix (currently, it aborts hinting).
5. LEFT to accept the hint and move the cursor to the left.
6. New key binding to accept the suggestion but keep cursor in place.

Thoughts?

I tried to call a PV Module as below code , But it given an erroe --> KeyError Traceback (most recent call last) ~\miniconda3\lib\site-packages\pandas\core\indexes\base.py in get_loc(self, key, method, tolerance) 3799 try: -> 3800 return self._engine.get_loc(casted_key) 3801 except KeyError as err:

~\miniconda3\lib\site-packages\pandas_libs\index.pyx in pandas._libs.index.IndexEngine.get_loc()

~\miniconda3\lib\site-packages\pandas_libs\index.pyx in pandas._libs.index.IndexEngine.get_loc()

pandas_libs\hashtable_class_helper.pxi in pandas._libs.hashtable.PyObjectHashTable.get_item()

pandas_libs\hashtable_class_helper.pxi in pandas._libs.hashtable.PyObjectHashTable.get_item()

KeyError: 'LONGi_Green_Energy_Technology_Co___Ltd__LR4_72HPH_450M'

The above exception was the direct cause of the following exception:

KeyError Traceback (most recent call last) ~\AppData\Local\Temp\ipykernel_17908\2790595467.py in <cell line: 23>() 21 22 modules = pvlib.pvsystem.retrieve_sam('CECMod') ---> 23 M = modules['LONGi_Green_Energy_Technology_Co___Ltd__LR4_72HPH_450M'] 24 25 print (M)

~\miniconda3\lib\site-packages\pandas\core\frame.py in getitem(self, key) 3803 if self.columns.nlevels > 1: 3804 return self._getitem_multilevel(key) -> 3805 indexer = self.columns.get_loc(key) 3806 if is_integer(indexer): 3807 indexer = [indexer]

~\miniconda3\lib\site-packages\pandas\core\indexes\base.py in get_loc(self, key, method, tolerance) 3800 return self._engine.get_loc(casted_key) 3801 except KeyError as err: -> 3802 raise KeyError(key) from err 3803 except TypeError: 3804 # If we have a listlike key, _check_indexing_error will raise

KeyError: 'LONGi_Green_Energy_Technology_Co___Ltd__LR4_72HPH_450M

When calling inspect.getsource() from within a function (let's call it g) on an upper frame, when that upper frame is the global ipython scope, only the first line of the code is present.

I'm not sure if this is a design flaw or something that changed recently but would like to hear your thoughts on this.

In [105]: def g(*x):
     ...:     upper_frame = sys._getframe(1)
     ...:     code = inspect.getsource(upper_frame)
     ...:     print(code)
     ...: 

In [106]: g(1,
     ...:   2)
g(1,

Do note, of course this issue is specifically a bare global scope issue. If we make the call to g inside a function, the source code is retrieved just fine (which makes sense since because there you have the function's frame)-

In [107]: def f():
     ...:     g(1,
     ...:       2)
     ...: 

In [108]: f()
def f(): 
    g(1,
      2)

I'm not too keen on how ipython actually manages its frame. I do know upper to the global scope is the run_code frame, and it seems to be that the issue is just retrieving from its child <cell line: 1>. I guess because ipython, even when stuff is multi line, stores in frame only cell line 1?

In [112]: sys._getframe(0
     ...: )
Out[112]: <frame at 0x2b066d0, file '<ipython-input-112-38b961076835>', line 1, code <cell line: 1>>

thanks

Hi!

Using ipython 8.7.0 I just identified that the block below always triggers the annoying warning when I run ipython within a pyenv venv.

https://github.com/ipython/ipython/blob/d38397b078b744839b8510f7ac9ab4fa40450a4f/IPython/core/interactiveshell.py#L886-L890

The instance variable warn_venv occurs two times in the whole module (here both locations in the snippets cutout) and seems to be always true.

https://github.com/ipython/ipython/blob/d38397b078b744839b8510f7ac9ab4fa40450a4f/IPython/core/interactiveshell.py#L511-L514

I see no point to always get that message although I clearly run the ipython executable in the currently active venv.

Maybe my symlink setup causes that?

Here you see something in my neovim session.

Top pane: the module where above code listings come from Middle pane: vars in a debug session in pdb Bottom pane: my symlink of $HOME/.pyenv and the env var VIRTUAL_ENV

Maybe someone wants to look deeper into that scenario. For now it looks like a warning that should not appear in this case and I disable it.

I wish a Merry Christmas, Jamil