Updating jsl scripts using Python to JMP 18

[#1]

We have jsl scripts that are calling python scripts that I now want to update for the new Python functionality of JMP 18.

Up to JMP 18, we did something like this to prepare the Python connection:

// Python setup
Python Init( Debug Print Statements( "TRUE" ),  Init Trace("TRUE"), Debug Print Output("TRUE") );
Python Submit(
	"\[
import numpy as _JMPnp
import scipy as _JMPsp
import pandas as _JMPpd
import sqlite3 as _JMPsq
if PY_DEBUG_OUTPUT:
	print("Python Imports OK")
]\"
);

Since Python Init () is now deprecated, I'm wondering a) if I even need now to initialize the python connection before using python send(), submit(), .... b) if yes, how I would do it using I guess using python connect ()

My current theory is, that I would need to replace the element above witth: 

Python connect();
Python submit  ( 
...blablabla...
);

but the documentation and examples are a bit sparse on this.

[#2 · Accepted solution]

Neither the Python Init() nor the Python Connect() are necessary to 'initialize' the Python environment in JMP 18.  Because Python is built-in and installed with JMP it is available immediately.  This is why the Python Init() was deprecated.  The Python Connect still exists to support use of a connection object.

conn = Python Connect();

conn << Get( dt );

conn << Submit("\[ ... python code ... ]\");

If you don't need the connection object you do not need either Python Init() or Python Connect(). you can simply do:

Python Submit(

... my code here ...

);

[#3]

I think my error of thought was that I needed some kind of initialization because I got errors that the packages I wanted were not found.

But after running jmputils.jpip('list'), I see that I need to install them first (I was assuming that standard packages like numpy or pandas would be preinstalled).

[#4]

JMP 18.0 only ships with the standard Python.org distribution, minus a few packages that might cause a conflict with Python running from within JMP.  Primarily this is tkinter and venv.  Any external packages need to be installed by the user.  There are a couple reasons.  Everything that JMP ships that is a 3rd-Party library, package or open source component, has to go through several approval processes internally including review by our Legal department.  It also means our watching that package for bug fix and security issues. Finally, package incompatibilities do exist, so our picking a package version means it could conflict with a package you need.  The power is in your hands to pick and choose the packages you need outside of what is shipped in the standard library.

Other items to note in porting JMP 14-17 Python scripts.

• Python Term();  is unnecessary since the environment only goes away when you shut down JMP.
• Python Get Graphics(); was removed from JMP 18. This single function caused a dependency on matplotlib. And the goal is to prevent JMP from requiring any external packages for basic functionality. It is easy enough to replicate the same functionality in your own scripts.  The Scripting Index example for 'Python Get Graphics();'  contains a complete example of the replacement code.  Simply save the figure to an image file and open the image in a JMP window.

  Python Submit("\[
  ...
  # save image to location of your choosing
  plt.savefig('/tmp/get_graphics_img.png')
  ]\");
  
  // plot = Python Get Graphics( png );       // DEPRECATED
  plot = Open( "/tmp/get_graphics_img.png", png );
  pngJMP = New Window( "Plot", Picture Box( plot ) );
  Python Submit( "plt.close()" );
  rc = Delete File( "/tmp/get_graphics_img.png" );

• Python Control() was used for setting some options with matplotlib.  While not removed in 18.0, its only function now is to print a 'deprecated' warning to the log.
• Python Is Connected(); is deprecated because it always returns true.  The Python environment is always available.

One last issues to note. We discovered an issue with mx = Python Get( numpy.ndarray );  If the NumPy array was greater than 2 dimensions you would get a result, but it would lose dimensions greater than two.  There was also an issue if the NumPy array's memory layout was Column-Major (Fortran style) rather than Row-Major( C style ).  This could result in a JMP crash.  This issue has been resolved. The fix will be present in JMP 18.1.  If you run into this in JMP 18.0, make sure your NumPy data is in Row-Major format and 'Get' only 1 or 2 Dimension ndarrays.   When you Get() a ndarray it tries to create a JSL Matrix which only supports either 1 or 2 dimensions. This bug is specific to JMP 18.0, since JMP 14-17 transferred the data through the file system as temporary binary file of doubles.  Though 14-17 might loose data if number of dimensions is greater than 2.