handling implicit prompt request in run time like colab

Offen

#513 erstellt am 10.6.2020 12 Kommentare 7 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 35/100

Issue-Typ: Feature
Klarheit: Größtenteils klar
Aktivitätsstatus: Ruhig
Tech-Stack: jupyter, jupyter-notebook, python
Bereich: backend

Rechercherichtung

Reproduziere das Verhalten mit !touch something.txt, gefolgt von !rm -i something.txt in JupyterLab, und lies anschließend das verlinkte JupyterLab-Issue #8522 für den relevanten Kontext. Als abgeschlossen gilt die Aufgabe, wenn implizite Laufzeit-Prompts dem Benutzer angezeigt werden, ohne dass die Kernel-Zelle dauerhaft weiterläuft, entweder durch einen Magic-Befehl oder native Unterstützung.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

I've recently encountered this problem that when my code has an implicit user input request, the Jupiter notebook isn't able to handle it and the kernel just keeps running until I manually interrupt it. If I explicitly use an input or read command the kernel will ask me for user input while running in a cell and the problem is for command requiring input without asking explicitly.

The google colab can handles such a situation without any problem and I'm asking for a magic command to do the same in Jupiter notebook and jlab. consider the following example which doesn't have any explicit input or read function associated with it:

!touch something.txt
!rm -i something.txt

If I run this code in colab, a prompt will come up and ask me if I want to delete something.txt. However, if I run the same code in jlab, the kernel keeps running in that cell and I get no prompt or any other output until I interrupt the kernel manually!!

So, this is a feature request for a new magic command or native support to watch for implicit input requests in run time, similar to what colab does natively without any magic.
The original problem was mentioned here
a StackOverflow question regarding this problem was asked here

Vorherrschende Sprache: Python
Sterne: 734
Forks: 411
Ø Merge: 1 T. 2 Std.
Gemergte PRs (30 T.): 9

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ipython/ipykernel

`Kernel._control_lock` created after it may be used Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100

ipython/ipykernel#1567 · 1 Kommentar · Erstellt am 22.9.2026
pytest seems to be the testrunner - not nose, as mentioned in README Offen

Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 72/100

ipython/ipykernel#554 · Erstellt am 17.10.2020
post_execute fires during comm_msg handling on a subshell, so output published from the hook is parented to the comm_msg and dropped by frontends Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100

ipython/ipykernel#1564 · Erstellt am 21.9.2026
Shell reply sent raw on the ROUTER can drop the ZMQStream wake-up; a request arriving in that window is not read until the next connection Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 68/100

ipython/ipykernel#1554 · 1 Kommentar · Erstellt am 07.9.2026
Interrupt on swallowed `KeyboardInterrupt` exceptions (`SIGINT`) when pressing twice (within 5 seconds) Offen

ipython/ipykernel#1550 · 1 Kommentar · 1 Reaktion · 1 zugewiesene Person · Erstellt am 25.8.2026

Alle Issues in ipython/ipykernel