[IPython-dev] From Pyro to IPython/Jupyter

Osborn, Raymond rosborn at anl.gov
Wed Dec 2 08:58:24 EST 2015


Frederic,
We have been testing the use of Pyro4 as a method of loading remote NeXus files within NeXpy, which also uses a Jupyter shell (http://nexpy.github.io/nexpy/). It’s not part of the official distribution yet, but I would be happy to discuss it with you outside this list. As a fellow neutron scatterer, it might be relevant.

Ray

On Dec 2, 2015, at 7:27 AM, Frédéric Mantegazza <mantegazza at ill.fr<mailto:mantegazza at ill.fr>> wrote:

Le 02/12/2015, Thomas a écrit :

You could make a custom execution environment which only exposes a
particular set of commands relevant to e.g. controlling a mass
spectrometer. But broadly, a kernel is there to be the execution backend
for a user typing in code, not an RPC framework. If you're happy with the
way you use Pyro, you'd probably have to do quite a bit of work to
reimplement a similar interface on top of our kernel/client model.

When we started to develop our application (aka PyMAD), we had in mind to
push the instrument responsible to dig into python, and offer him
something closer to a framework, rather than a end-user application.

This, because this guy is someone with 1000 ideas per hour, and often asks
for new stuffs. So, giving to him such (very) high level tools to control
his instrument could have been nice.

But He never dig enough into python to be able to do so. I don't blame him
at all, as it is not easy to change habits. Python was new to him...

But he is about to retire, at the end of this year, and the new
responsible is younger, and uses python to treat his scientific datas. So,
I think it could be nice, this time, to implement what we always wanted to
do.

Saying this, it appears to me that we don't really need a RPC-like
framework, and exposing all the internals of the application could be
great. We will have to find a mecanism to hide some parts for simple users
using the instrument, to avoid them to brake things during their
experiment (:o/), but I think it can be done without too much work.

On the other hand, having the jupyter mecanism, and being able to start a
session from one place, in a pure console, or in a qtconsole, them
go back home and switch to a web-based console to continue to work from
the same point is really great.

Last, it appears that Pyro4 dropped some features mandatory for our
application, like the event service! So, we are stuck to the 3.x version...

That's why I want to explore this idea.

--
   Frédéric MANTEGAZZA             CEA-Grenoble
   Tel.     : 33 (0) 476 207 617   INAC/SPSMS/MDN
   Fax      : 33 (0) 476 483 906   17, rue des Martyrs
   Courriel : mantegazza at ill.fr<mailto:mantegazza at ill.fr>    F-38054 Grenoble Cedex 09

_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org<mailto:IPython-dev at scipy.org>
https://mail.scipy.org/mailman/listinfo/ipython-dev

--
Ray Osborn, Senior Scientist
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: ROsborn at anl.gov<mailto:ROsborn at anl.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20151202/18e39399/attachment.html>


More information about the IPython-dev mailing list