Standardization of API provided to the Python runtime

Offen

#475 erstellt am 09.1.2020 1 Kommentar 0 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: 20/100

Issue-Typ: Feature
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: python
Bereich: api

Rechercherichtung

Beginne mit der Prüfung des verknüpften ipywidgets issue 2665 und dem Vergleich der von xeus-python verwendeten IPython- und ipykernel-APIs. Lege den Umfang und die Kompatibilitätsanforderungen für eine gemeinsame Python-Kernel-API fest, einschließlich der Frage, ob ein dynamisch erstelltes Kernel-Modul geeignet ist; die Arbeit ist abgeschlossen, wenn die API-Grenze und der Übernahmepfad vereinbart sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

With the new Python kernels which are now arising, it may be interesting to define a scoped API that a Python kernel must make available for the Python runtime.

For example, xeus-python monkey-patches IPython.display, IPython.clear_output, etc... I just opened https://github.com/jupyter-widgets/ipywidgets/issues/2665 in ipywidgets to list the IPython and ipykernel APIs that we are using and may be included in this limited API.

Instead of monkey-patching and using the IPython module, a way to go may be for the kernel to dynamically create a "kernel" python module that has all these functions...

This somewhat goes along the lines of @Carreau's remark on points of convergence between ipykernel and xeus-python:

If users needs to switch between ipykernel and Xeus-python depending on wether they want to use a given magic or the debugger the experience will be sub-par. If we have to choose, a clear distinction of features would be better than two almost similar projects.

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