Integration via official VSCode Python API

[hoangKnLai]

See python-extension-template for

• Update ms-python dependency, activation, and usages
• Potential integration of ipython via direct usage

[hoangKnLai]

[Notebook API]() may provide a path to:

• Integrate with IPython kernel officially like ms-jupyter extension but using one cell only
• Allow display of matplotlib plots in the output instead

[AmerM137]

@hoangKnLai a few questions about the Notebook API:

• Does the API provide a way to have a proper terminal application? With the current implementation of the jupyter extension "interactive window", it seems that it's still a "write code in cell and send to terminal as one section" workflow, i.e. it's not a true REPL experience like IPython. Ideally, you would want something that replicates the Spyder editor->REPL workflow exactly.
• The biggest thing missing (if you agree) with the current integrated terminal is the ability to communicate to the terminal to identify when it has completed "running some code". Due to lack of such feature, we have to rely on delaying commands to avoid race conditions. Is there a way we can implement a queue of some kind to work around this? Or better yet, does the Notebook API expose any functionality we can leverage to communicate properly to the terminal? Do we have to have a kernel running in the terminal to allow for such two-way communication?
• Spyder uses a qtconsole for the integrated terminal instead of the ipython terminal, which provides in-line plotting and other features. Is it possible to implement anything like that in VSCode? or is the fact that qtconsole is a GUI app prevent us from doing that?
• Is there any way for VSCode to communicate with an external terminal? This way we can have an editor on the one side and either a qtconsole / ipython terminal / any terminal running in any terminal emulator that can receive the code sent from the editor. I think this opens up the door for a lot more customizations.

[hoangKnLai]

Ideally, you would want something that replicates the Spyder editor->REPL workflow exactly.

Yes. The REPL behavior is what we wanted. I think IPython does this in two ways:

• Text terminal version (what we are currently using) implements the standard REPL interface via stdstream
• Python API in which the ipython kernel can be created and queried
  • I believe the qtconsole and Spyder uses this one.

Spyder uses a qtconsole for the integrated terminal instead of the ipython terminal, which provides in-line plotting and other features. Is it possible to implement anything like that in VSCode? or is the fact that qtconsole is a GUI app prevent us from doing that?

About a year back, I looked briefly into the qtconsole:

• It seems that qt API for typescript/javascript is not a thing. If it is, we likely can trigger qt-event for the qtconsole to use.
• qtconsole communicate via some IP socket which is slow when compare to current sent text.
• Done some quick test and it is also difficult to update the qtconsole rendering (e.g., a code snippet can be ran on its kernel, but I couldn't find a way for it to print the In [ ] / Out [ ]) of a command.
• Spyder can use qtconsole directly since it is built in qt-python hook

Is there any way for VSCode to communicate with an external terminal?

There might be one. Similar to a language server, the @vscode/python-extension provides a tunnel between vscode and python. Hence this issue to find the way. An approach might be:

• Create an ipython service server via the python-extension option
  • The services are the usual code execution options
• Within the server, vscode can query services (it is likely that Jupyter extension uses this)
  • With Jupyter, they do this per cell and keep the cell which is bad
  • Using the notebook API, we might be able to enforce a single input / output cell which replicate the REPL behavior

So the main idea stems from the fact that vscode notebook can already render the ipython kernel inputs and outputs including the inline plots that the current text terminal can't. All we do is likely managing the various kernel, the number of notebook cells, and what is being render.

• A likely downside: the coms between the notebook-python-ipython-ipykernel are likely to be slower than the current text stream