824895_fr-FR

liliconcom

Fournir un mécanisme de redémarrage du noyau Python

Qu'est-ce qui a inspiré cette demande de liste de souhaits ?

Le développement de code Python à exécuter dans JMP implique généralement le clonage d'un référentiel Github et le pointage de JMP vers la copie locale du code comme suit :

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

Quelle amélioration souhaiteriez-vous voir ?

Fournir un mécanisme (bouton, API, ??) permettant à l'utilisateur de redémarrer le noyau Python, sans avoir à fermer et rouvrir JMP.

Pourquoi cette idée est-elle importante ?

Au cours du développement du code, de nombreuses modifications sont apportées au code local, chacune nécessitant le chargement du nouveau code dans le noyau Python. Actuellement, la seule façon de charger un nouveau code local dans le noyau Python est de fermer et de redémarrer JMP. Cela ralentit considérablement le développement et peut constituer un obstacle pour certains développeurs.

Automatisation et scriptsRe: Fournir un mécanisme de redémarrage du noyau Python

Premier code modifié dans l'éditeur et réexécuté, s'exécute avec les modifications.

S'il s'agit de code que vous avez importé

importer mon code

# lorsque vous devez forcer le rechargement du package 'mycode'

importer importlib

importlib.reload(moncode)

Il s'agit d'un comportement Python existant. La plupart du temps, vous ne voyez pas ce comportement car Python est exécuté à partir de la ligne de commande et le script et Python se terminent entre les exécutions. Étant donné que JMP charge la bibliothèque partagée Python, vous devez considérer JMP comme Python dans ces cas. Si vous deviez effectuer le même travail dans la console interactive Python (c'est-à-dire IDLE), sans quitter entre les modifications, vous verriez le même comportement. L'environnement Python reste actif depuis la première utilisation jusqu'à la fermeture de JMP car l'environnement est partagé. C'est ainsi que l' intégration JSL / Python peut être implémentée.

Donc non, nous ne fournirons pas de « redémarrage » pour le moment, car le package importlib.reload() répond à ce besoin.

Nous étudions la possibilité de lancer des sous-interpréteurs Python indépendants. Cela permettrait de nombreuses fonctionnalités supplémentaires, telles que l'exécution d'un script dans un environnement plus propre si nécessaire. L'étude des sous-interpréteurs est l'une des raisons pour lesquelles JMP 19 passe à Python 3.13.x. Les mises à jour et le cycle de vie de la sécurité sont les principaux moteurs de la mise à jour vers 3.13.x

Re : Fournir un mécanisme de redémarrage du noyau Python - Statut modifié en : Non prévu pour l'instantRe: Fournir un mécanisme de redémarrage du noyau Python

Hm. J'apprécie la possibilité de partager toutes mes variables entre différentes fenêtres de script Python et tâches en arrière-plan.
J’aurais aimé qu’Application Builder ait cette option !

Mais je dois admettre que cela semble un peu « expérimental ».
La réinitialisation du noyau par un redémarrage est ce à quoi nous sommes habitués - depuis 1995 - c'est tellement confortable.
De nombreux autres (!!!) IDE Python fournissent cette fonctionnalité - d'autres exécutent le code puis ferment le noyau.

« exécuter un script dans un environnement propre »
... cela semble prometteur.

Je suppose que le démarrage (et le redémarrage) de ces sous-interprètes est alors disponible automatiquement .
Je me demande pourquoi « non ». Cela nous donne la fonctionnalité qui nous manque dans JMP ?

Re: Fournir un mécanisme de redémarrage du noyau Python

Le plus gros problème est qu'une bibliothèque partagée chargée en mémoire ne peut pas être déchargée par le processus en cours d'exécution. Cela s'applique non seulement à Python lui-même, mais également aux packages Python importés qui ont une bibliothèque partagée comme NumPy. Python ne s'exécute pas dans un autre espace de processus, mais dans et en tant que partie de JMP lui-même. Oui, Py_Finalize() peut être appelé et Py_Initialize() ultérieur pour initialiser l'interpréteur une deuxième fois. Le problème que j'ai rencontré dans le passé était que NumPy ne réagissait pas particulièrement bien à l'importation après la deuxième initialisation de l'interpréteur. JMP est devenu instable et sujet au plantage, en particulier lors de l'importation de NumPy après le redémarrage. Je n'ai pas regardé comment les autres IDE gèrent Python, mais ils peuvent très bien exécuter une instance de Python au lieu d'intégrer Python.

Nous avons considérablement amélioré la gestion de la mémoire dans JMP 18 par rapport aux versions précédentes. Il peut donc être utile de revoir cela pour voir si un tel redémarrage est réalisable. Il se peut que cela soit dû à notre gestion de la mémoire ou que cela soit toujours un problème avec NumPy et d'autres packages qui chargent des bibliothèques partagées.