Support fully integrated IPython terminal

The Python IDE Spyder runs code in an IPython terminal integrated in the IDE. The IPython terminal opens along with the rest of the IDE and when you run a script, it gets run directly via %run in existing IPython terminal. The terminal remains open after execution of a script so that you can access variables in its context afterwards.
I sorely miss this feature in VSCode and it would be absolutely great if this could be offered by the Python extension. Spyder is open source, so it should be possible to see how they have implemented it.

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

See also #17172. I'd also like to be able to use IPython instead of the regular interactive Python interpreter.

I'd also like to be able to use IPython instead of the regular interactive Python interpreter.
👍

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

BTW please let us know what you specifically miss from IPython.

Magic commands and colored input and output :)

I'd also add the ability to run shell commands (e.g. !ls) as well as Matplotlib event loop integration via %matplotlib (very useful for interactive data analysis).

BTW please let us know what you specifically miss from IPython.

terminal functionality such as completions

Ditto for syntax highlighting and code completions. If possible, it would also be amazing if ipdb was supported!

I'm new to VSCode (coming here from Spyder because work uses VSCode), so apologies if these sorts of functionalities are available and I just haven't found them yet (and yes, I know that the debug console is a thing and some of the stuff I'm going to list can sort of be approximated in the debug console). Here's my list of the main things I find useful about the iPython console in Spyder:

The ability to run a portion of my code (e.g., the part I've got working that loads in some data) and then have access to view & manipulate the namespace variables, test lines of code, etc. This is one of the things the debug console can approximate, but you don't have to keep mucking around with setting/clearing breakpoints.
The ability to run multi-line code snippets (e.g., a for loop). I haven't been able to get this to work in the debug console
using ? to open up a functions docstring (e.g., running np.random.random? or pd.DataFrame? in the iPython console) can be a much quicker way to get basic documentation

2. The ability to run multi-line code snippets (e.g., a for loop). I haven't been able to get this to work in the debug console

That won't work as it isn't designed for that. Are you not using our REPL support, which supports sending multi-line code, because it lacks a variable viewer?

Brett Cannon (@brettcannon)

The ability to run multi-line code snippets (e.g., a for loop). I haven't been able to get this to work in the debug console
That won't work as it isn't designed for that. Are you not using our REPL support, which supports sending multi-line code, because it lacks a variable viewer?

Brett Cannon (@brettcannon) Thanks for the response. To be honest, I'm very new to VSCode, so I wasn't aware that REPL support was a thing. But yes, the lack of a variable viewer would be somewhat annoying.

Brett Cannon (@brettcannon)

hello Brett Cannon (@brettcannon),

My use case for IPython is launching a debug session with IPython. The Databricks VSCode extension adds an IPython startup script that sets some environment variables and initializes a Spark session.

However, when using the default VSCode Python debugger, which is a standard Python interpreter rather than the IPython one, the IPython startup script is not executed.

I tried this config in launch.json, but it doesn't wok:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "IPython Debugger: Current File",
      "type": "debugpy",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
      "python": "${workspaceFolder}/.venv/bin/ipython"
    }
  ]
}

Anthony Kim (@anthonykim1)

/cc Anthony Kim (@anthonykim1)

Thanks everyone for showing interest in this.

As I mentioned #17172 (comment), I'd like to know what folks think about the new Native REPL and get some feedback on what specific features folks really want from iPython in terminal.
Thank you in advance for your opinions.

I have to say that I stopped using IPython, because the new REPL in Python 3.13 is good enough for me. I'd prefer using that over the Native REPL, since a terminal-based REPL has been the go-to method for interactive computing for me, as it is also available in many other languages. Therefore, I'd rather have a good terminal REPL experience than a custom "native" REPL (but unfortunately there are still a couple of issues, such as the indentation issue on Windows, the fact that running the entire script and running single lines/selections in the REPL use the same terminal, etc.).

Anthony Kim (@anthonykim1)

Thanks Anthony Kim (@anthonykim1) for asking about this!

This might be slightly off-topic but I wanted to say that I'm still struggling to understand the motivation behind the native REPL.

I've been a VS Code Python user for many years, and I have two distinct use cases for running my code:

interactive, which involves (re)running code segments individually and generating static or interactive figures
non-interactive: an entire script runs completely from beginning to end and then exits

The first case is already covered through using code cells together with the Interactive Python window.

The second case is covered by the Run button, which spawns a Python interpreter on the command line and runs my code.

I don't understand which use case the native REPL is addressing -- maybe because I'm not in the target audience? What's the goal here? I see it can spawn an interactive-window-like experience without requiring a Jupyter kernel, but I don't see how this brings me any advantages either? I've got plenty of SSD storage, and dev-only dependencies (for interactive development) are declared as such, so they won't get deployed after development has been finished and we go into production.

Would you be so kind as to help me understand what the native REPL is all about? I know for a fact that several of my friends and colleagues -- all faithful users of VS Code for many years now!! -- feel the same: they're confused and hence don't use the native REPL at all so far.

Thank you so much for your input!

Richard

Clemens Brunner (@cbrnr)

Thanks Clemens Brunner (@cbrnr) Richard Höchenberger (@hoechenberger) for your valuable feedbacks. I truly appreciate them.

After couple months of launching native REPL we also do see portion of users favoring terminal REPL over native REPL, and also vice versa.

We do recognize the native REPL can be very opinionated product in terms of its positioning. That being said, we are not planning to discard REPL in terminal, but are aiming to provide best REPL experience for people in both category (whether they enjoy REPL in terminal or in Editor via Native REPL)

Some of the motivation behind creation of Native REPL was to provide features that were originally only available in the higher fidelity Jupyter Notebook or via inside the Editor. These include features such as Intellisense, Syntax Highlighting.
Now we also have access to copilot inline chat and variable viewer in the native REPL. All without having to install Jupyter Notebook extension or ipykernel, which turned off many folks from using Jupyter notebook or Interactive Window with these provided features. Native REPL is hopefully sufficient enough for some, if not would provide good gateway path to Jupyter or even have people go back to REPL in terminal or IPython.

I do think these features can go into REPL in terminal and lot of folks who still favor REPL in terminal experience would benefit from this (check out terminal suggest for different shell types atm) eventually :)
Best,

Navigation Menu

Repository navigation

Support fully integrated IPython terminal #22139

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support fully integrated IPython terminal #22139

Description

Activity

github-actions commented on Oct 3, 2023

cbrnr commented on Oct 25, 2023

tomazfs commented on Nov 27, 2023

brettcannon commented on Dec 7, 2023

brettcannon commented on Dec 7, 2023

m-ganko commented on Dec 7, 2023

cbrnr commented on Dec 8, 2023

jamesowers-cohere commented on Dec 8, 2023

NedJWestern commented on Dec 20, 2023

jeremymatt commented on Jan 5, 2024

brettcannon commented on Jan 8, 2024

jeremymatt commented on Jan 8, 2024

copdips commented on Nov 10, 2024

brettcannon commented on Nov 12, 2024

anthonykim1 commented on Dec 10, 2024

cbrnr commented on Dec 11, 2024

hoechenberger commented on Dec 11, 2024

anthonykim1 commented on Jan 5, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions