cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Choose Language Hide Translation Bar
View Original Published Thread


Provide a Python kernel restart mechanism

What inspired this wish list request? 

Developing Python code to run in JMP typically involves cloning a Github repository and pointing JMP to the local copy of the code as so:

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

 

 

What is the improvement you would like to see? 

Provide a mechanism (button, API, ??) for the user to restart the Python kernel, without having to close and re-open JMP.

 

Why is this idea important? 

During code development, there are numerous changes to the local code, each requiring the new code to be loaded into the Python kernel.  Currently, the only way to get new local code loaded into the Python kernel is to close and restart JMP.  This slows down development significantly and could be a blocker for some developers. 

 

 

4 Comments
Paul_Nelson
Staff

First code changed in the editor and re-run, runs with the changes.

 

If it's code you've imported

 

import mycode

 

# when you need to force reloading the 'mycode' package

import importlib

importlib.reload(mycode)

 

This is existing Python behavior.  Most of the time you don't see this behavior because Python is run from the command line and the script and Python exit between runs.  Since JMP loads the Python shared library you have to think of JMP as Python in these cases.  If you were to do the same work within the Python interactive console (ie. IDLE), without exiting between changes you would see the same behavior.   The Python environment stays live from the first use until JMP exits because the environment is shared.  It's how the JSL / Python integration is able to be implemented.  

 

So no, we won't be providing a 'restart' at this time, as the importlib.reload( package ) satisfies this need.

 

We are investigating the ability to launch independent Python Sub-Interpreters.  This would allow lots of additional capabilities such as running a script in a clean(er) environment when needed.  Investigation into sub-Interpereters is is one of the reasons JMP 19 moves up to Python 3.13.x .  Updates and security lifecycle is the primary driver of the update to 3.13.x

mia_stephens
Staff
Status changed to: Not Planned For Now
 
hogi
Level XII

Hm. I enjoy the possibility to share all my variables between different Python script windows and tasks in the background.
I wished Application Builder had this option!

 

But I have to admit, it feels a bit "experimental".
Resetting the Kernel by a restart is what we got used to - since 1995 -  it feels so comfortable.
Many other (!!!) Python IDEs provide this feature - others run the code and then close the Kernel.

 

"running a script in a clean(er) environment"
... sounds promising.

 

I guess that starting (and restarting) such Sub-Interpreters is then available automatically.
I wonder why "no". This gives us the functionality we miss in JMP?

Paul_Nelson
Staff

The biggest issue is that a shared library loaded into memory can't be unloaded by the running process.  This applies not only to Python itself, but imported Python packages that have a shared library like NumPy.  Python isn't running in another process space but within and as part of JMP itself.  Yes, Py_Finalize() can be called and s subsequent Py_Initialize() to Initialize the interpreter a second time.  The issue I ran into in the past was that NumPy did not react particularly well to import after the second interpreter initialization.  JMP became unstable and prone to crashing, especially on the import of NumPy after restart.  I have not looked at how the other IDEs handle Python, but they may well be running an instance of Python instead of embedding Python.

 

We have cleaned up memory handling in JMP 18 quite a bit from previous versions,  so it may be worth revisiting this to see if such a restart is feasible.  It may have been our memory handling or it may still be an issue with NumPy and other packages that load shared libraries.