[IPython-dev] variable information request

Brian Granger ellisonbg at gmail.com
Sun Apr 10 01:59:32 EDT 2011


On Sat, Apr 9, 2011 at 4:53 AM, Jason Grout <jason-sage at creativetrax.com> wrote:
> Here's a crazy idea that could lead to some nice interactively-updating
> components of an IPython frontend.  Right now, in the new messaging
> protocol, it appears that I can send a computation request and then ask
> for the output to contain the values of several variables (the
> "user_variables" field of a execute_reply message).  However, what if I
> want to check the value of a variable *during* a computation and get an
> immediate response?  I might, for example, have a box that prints out
> the current value of a root approximation, for example, or a slider that
> contains the current iteration number, and I want these to be updated
> fairly frequently while the computation is running.

I think this is where the display system comes in.  We have extended
the model of the displayhook to allow that macheniery to be triggered
by users anywhere in their code by simply calling our top-level
display functions:


Calling these functions causes a JSON message to be sent to all
frontends instantly (it doesn't wait for the code to finish).  These
messages can have extra metedata and a A given frontend could easily
look at that metadata and decide how to display the JSON data.

> Here's one way to do it, I think:  Run a separate thread that just
> answers these queries.  Since the GIL handles access to variables, I
> think it's okay for the separate thread to retrieve the value of a
> variable and return that, and it seamlessly does this while the main
> thread is carrying on a computation.  For example, the following code
> will print out the current iteration number every time enter is pressed:

Almost always, in Python, threads are not the answer.  This type of
service would go down the second that non-GIL releasing extension code
is run.  This is one of the main reasons we have gone to pyzmq, as all
of its networking stuff is handled in GIL releasing C++ threads.  The
benefit of the existing display logic that uses pyzmq is that it will
continue to work fine in these situations.



> --------------------------------------
> from threading import Timer, Thread
> import time
> def printi():
>     global i
>     while True:
>         raw_input('Press enter to see the iteration number')
>         print i
> t=Thread(target=printi)
> t.daemon=True
> t.start()
> for i in range(20):
>     time.sleep(.5)
> ---------------------------------------
> I can see a problem if the value you are querying actually changes the
> object state in the middle of another computation using that object. But
> simple queries about an object's value should work fine, and maybe we
> could leave it up to the user to not mess up a currently-running
> computation by changing an object state.
> What do people think?
> Thanks,
> Jason
> --
> Jason Grout
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com

More information about the IPython-dev mailing list