824895_es-ES

liliconcom

Proporcionar un mecanismo de reinicio del kernel de Python

¿Qué inspiró esta solicitud de lista de deseos?

El desarrollo de código Python para ejecutarlo en JMP generalmente implica clonar un repositorio de Github y apuntar JMP a la copia local del código de la siguiente manera:

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

¿Cuál es la mejora que le gustaría ver?

Proporcionar un mecanismo (botón, API, ??) para que el usuario reinicie el kernel de Python, sin tener que cerrar y volver a abrir JMP.

¿Por qué es importante esta idea?

Durante el desarrollo del código, se producen numerosos cambios en el código local, cada uno de los cuales requiere que el nuevo código se cargue en el núcleo de Python. Actualmente, la única forma de cargar el nuevo código local en el núcleo de Python es cerrar y reiniciar JMP. Esto ralentiza significativamente el desarrollo y podría ser un obstáculo para algunos desarrolladores.

Automatización y scriptingRe: Proporcionar un mecanismo de reinicio del kernel de Python

El primer código se modifica en el editor y se vuelve a ejecutar, se ejecuta con los cambios.

Si es código que has importado

importar mycode

# cuando necesitas forzar la recarga del paquete 'mycode'

importar importlib

importlib.reload(micódigo)

Este es un comportamiento existente de Python. La mayoría de las veces no se ve este comportamiento porque Python se ejecuta desde la línea de comandos y el script y Python salen entre ejecuciones. Dado que JMP carga la biblioteca compartida de Python, debe pensar en JMP como Python en estos casos. Si tuviera que hacer el mismo trabajo dentro de la consola interactiva de Python (es decir, IDLE), sin salir entre cambios, vería el mismo comportamiento. El entorno de Python permanece activo desde el primer uso hasta que JMP sale porque el entorno es compartido. Así es como se puede implementar la integración de JSL / Python.

Por lo tanto, no proporcionaremos un 'reinicio' en este momento, ya que importlib.reload(paquete) satisface esta necesidad.

Estamos investigando la posibilidad de lanzar subintérpretes de Python independientes. Esto permitiría muchas capacidades adicionales, como ejecutar un script en un entorno más limpio cuando sea necesario. La investigación sobre los subintérpretes es una de las razones por las que JMP 19 se actualiza a Python 3.13.x. Las actualizaciones y el ciclo de vida de la seguridad son el principal impulsor de la actualización a 3.13.x.

Re: Proporcionar un mecanismo de reinicio del kernel de Python: estado cambiado a: No planificado por ahoraRe: Proporcionar un mecanismo de reinicio del kernel de Python

Hm. Disfruto de la posibilidad de compartir todas mis variables entre diferentes ventanas de scripts de Python y tareas en segundo plano.
¡Deseo que Application Builder tuviera esta opción!

Pero tengo que admitir que parece un poco "experimental".
Restablecer el kernel mediante un reinicio es a lo que nos hemos acostumbrado desde 1995: se siente muy cómodo.
Muchos otros (!!!) IDE de Python proporcionan esta función; otros ejecutan el código y luego cierran el kernel.

"Ejecutar un script en un entorno más limpio"
... suena prometedor.

Supongo que entonces el inicio (y reinicio) de dichos subintérpretes estará disponible automáticamente .
Me pregunto por qué no. ¿Esto nos brinda la funcionalidad que nos falta en JMP?

Re: Proporcionar un mecanismo de reinicio del kernel de Python

El mayor problema es que una biblioteca compartida cargada en la memoria no puede ser descargada por el proceso en ejecución. Esto se aplica no solo a Python en sí, sino a los paquetes Python importados que tienen una biblioteca compartida como NumPy. Python no se ejecuta en otro espacio de proceso, sino dentro y como parte de JMP. Sí, se puede llamar a Py_Finalize() y al subsiguiente Py_Initialize() para inicializar el intérprete una segunda vez. El problema con el que me encontré en el pasado fue que NumPy no reaccionaba particularmente bien a la importación después de la segunda inicialización del intérprete. JMP se volvió inestable y propenso a fallar, especialmente en la importación de NumPy después del reinicio. No he mirado cómo los otros IDE manejan Python, pero es posible que estén ejecutando una instancia de Python en lugar de incrustar Python.

Hemos mejorado bastante el manejo de la memoria en JMP 18 en comparación con versiones anteriores, por lo que puede que valga la pena volver a revisar esto para ver si es posible reiniciarlo. Es posible que haya sido el manejo de la memoria o que todavía haya un problema con NumPy y otros paquetes que cargan bibliotecas compartidas.