824895_de-DE

liliconcom

Bereitstellung eines Mechanismus zum Neustarten des Python-Kernels

Was hat Sie zu dieser Wunschliste inspiriert?

Das Entwickeln von Python-Code zur Ausführung in JMP umfasst normalerweise das Klonen eines Github-Repositorys und das Verweisen von JMP auf die lokale Kopie des Codes wie folgt:

jmputils.jpip('install','myrepo c:\\pathto\\myrepo')

Welche Verbesserung würden Sie gerne sehen?

Stellen Sie einen Mechanismus (Schaltfläche, API, ??) bereit, mit dem der Benutzer den Python-Kernel neu starten kann, ohne JMP schließen und erneut öffnen zu müssen.

Warum ist diese Idee wichtig?

Während der Codeentwicklung kommt es zu zahlreichen Änderungen am lokalen Code, die jeweils das Laden des neuen Codes in den Python-Kernel erfordern. Derzeit besteht die einzige Möglichkeit, neuen lokalen Code in den Python-Kernel zu laden, darin, JMP zu schließen und neu zu starten. Dies verlangsamt die Entwicklung erheblich und könnte für einige Entwickler ein Hindernis darstellen.

Automatisierung und SkriptingBetreff: Einen Mechanismus zum Neustarten des Python-Kernels bereitstellen

Zuerst den Code im Editor ändern und erneut ausführen, er läuft mit den Änderungen.

Wenn es sich um Code handelt, den Sie importiert haben

mycode importieren

# wenn Sie das Neuladen des Pakets „mycode“ erzwingen müssen

Importieren von Importlib

importlib.reload(mein Code)

Dies ist ein bestehendes Python-Verhalten. Meistens sehen Sie dieses Verhalten nicht, da Python über die Befehlszeile ausgeführt wird und das Skript und Python zwischen den Ausführungen beendet werden. Da JMP die gemeinsam genutzte Python-Bibliothek lädt, müssen Sie sich JMP in diesen Fällen als Python vorstellen. Wenn Sie dieselbe Arbeit in der interaktiven Python-Konsole (d. h. IDLE) ausführen würden, ohne zwischen den Änderungen zu beenden, würden Sie dasselbe Verhalten sehen. Die Python-Umgebung bleibt von der ersten Verwendung an aktiv, bis JMP beendet wird, da die Umgebung gemeinsam genutzt wird. So kann die JSL/Python-Integration implementiert werden.

Also nein, wir werden zu diesem Zeitpunkt keinen „Neustart“ bereitstellen, da das Paket importlib.reload() diesen Bedarf erfüllt.

Wir untersuchen die Möglichkeit, unabhängige Python-Sub-Interpreter zu starten. Dies würde viele zusätzliche Funktionen ermöglichen, wie z. B. das Ausführen eines Skripts in einer saubereren Umgebung, wenn nötig. Die Untersuchung von Sub-Interpretern ist einer der Gründe, warum JMP 19 auf Python 3.13.x aktualisiert wird. Updates und Sicherheitslebenszyklus sind der Hauptgrund für das Update auf 3.13.x.

Betreff: Einen Neustartmechanismus für den Python-Kernel bereitstellen – Status geändert in: Derzeit nicht geplantBetreff: Einen Mechanismus zum Neustarten des Python-Kernels bereitstellen

Hm. Ich genieße die Möglichkeit, alle meine Variablen zwischen verschiedenen Python-Skriptfenstern und Aufgaben im Hintergrund zu teilen.
Ich wünschte, Application Builder hätte diese Option!

Aber ich muss zugeben, es fühlt sich ein bisschen „experimentell“ an.
Das Zurücksetzen des Kernels durch einen Neustart ist das, woran wir uns seit 1995 gewöhnt haben – es fühlt sich so bequem an.
Viele andere (!!!) Python-IDEs bieten diese Funktion – andere führen den Code aus und schließen dann den Kernel.

„Ausführen eines Skripts in einer saubereren Umgebung“
...klingt vielversprechend.

Ich vermute, dass das Starten (und Neustarten) solcher Unterinterpreter dann automatisch möglich ist.
Ich frage mich, warum „nein“. Dadurch erhalten wir die Funktionalität, die wir in JMP vermissen?

Betreff: Einen Mechanismus zum Neustarten des Python-Kernels bereitstellen

Das größte Problem ist, dass eine in den Speicher geladene gemeinsam genutzte Bibliothek nicht vom laufenden Prozess entladen werden kann. Dies gilt nicht nur für Python selbst, sondern auch für importierte Python-Pakete, die eine gemeinsam genutzte Bibliothek wie NumPy haben. Python läuft nicht in einem anderen Prozessbereich, sondern innerhalb und als Teil von JMP selbst. Ja, Py_Finalize() kann aufgerufen werden und anschließend Py_Initialize(), um den Interpreter ein zweites Mal zu initialisieren. Das Problem, auf das ich in der Vergangenheit gestoßen bin, war, dass NumPy nach der zweiten Initialisierung des Interpreters nicht besonders gut auf den Import reagierte. JMP wurde instabil und stürzte ab, insbesondere beim Import von NumPy nach dem Neustart. Ich habe mir nicht angesehen, wie die anderen IDEs mit Python umgehen, aber sie führen möglicherweise eine Instanz von Python aus, anstatt Python einzubetten.

Wir haben die Speicherverwaltung in JMP 18 im Vergleich zu früheren Versionen ziemlich aufgeräumt, daher lohnt es sich möglicherweise, dies noch einmal zu überprüfen, um zu sehen, ob ein solcher Neustart möglich ist. Möglicherweise lag es an unserer Speicherverwaltung oder es liegt immer noch ein Problem mit NumPy und anderen Paketen vor, die gemeinsam genutzte Bibliotheken laden.