CODEWITHSUNDEEP
pythonjupyter-notebook
bht
bht

Reputation: 848

How to embed Jupyter-notebook inside Python code with access to caller's environment

Often when I develop code I want to work inside the environment where that code will run. Typically I do this by invoking an IPython interpreter [which I do by setting PYTHONBREAKPOINT to point to a routine that calls IPython.terminal.embed.InteractiveShellEmbed()]. I am thinking that it would be way better to do this from Jupyter, where I would end up with a notebook that I could then use to write the final code. To give an example,

class Myobj(object):
    def __init__(self,arg1,arg2):
        self.a1 = arg1
        self.a2 = arg2
    def doSomething(self):
        breakpoint()

test = Myobj(2,3)
test.doSomething()

Then when my breakpoint runs I end up in Pdb (or with my extension, IPython) and I can access self.a1, etc.

I have tried starting up a notebook server with the following code:

j = 1
t = 'test string'
from notebook.notebookapp import NotebookApp
app = NotebookApp()
app.initialize(["--port", "8888"])
app.start()

This sort-of-works in that I get a browser window where I can start a notebook, but the global variables I have previously defined are not carried in to the kernel.

I'd think that what I want to do must be possible. This is Python after all.

Upvotes: 0

Views: 524

Answers (1)

Wayne
Wayne

Reputation: 9780

AN OPTION:

I would think you'd start Jupyter already in your environment and then work from there in conjunction with developing your code via your text editor. That way you'd iterate iterate over testing it with the settings in the notebook kernel, and using the notebook's debugging interactive prompt mode. And then further develop based on that.
You can then further develop in the notebook or related code text or just use the notebook to document associated trials and development.
I've put together code and a notebook that takes advantage of the Jupyter's features and abilities to do something along the lines of what you describe, yet in a different order. The code difference is really just a different route to trigger the interactive ipython shell that works with Jupyter. Because I condensed it to all one notebook for ease you'll have to overlook the clunkiness to see what I'm trying to illustrate, which can be viewed and run actively here via the MyBinder service.
Or the static form viewed here or the active form here after the session spins up.

What I put in the [In] input prompt when in the interactive mode doesn't show in the static view but can be seen by examining the raw code here. Basically in first it was:

  • j
  • t
  • self.a1
  • exit()

And then in second:

  • j
  • t
  • self.ai. TYPO. oops.
  • self.a1
  • exit()

There is also in Jupyter, the magic %load command which would read your code text and then let you run it in the notebook namespace. (You can see magic command %load illustrate with images here.) However, the two versions become distinct subsequent to that. That is why I prefer %run -i for developing usually.

related abilities: JupyterLab allows you to connect a full IPython console in the namespace of any notebook at any time, see here. This window can can be arranged as you wish, see here.

Plus you can now share kernels between notebooks in JupyterLab, see here.

related tech: There is also importnb that allows you to import a notebook. This seems backwards from most of what you want but ot does allow that you can even pass in variables in the command line, which is why I bring it up in regards to your seeking to pass things into notebooks, as mentioned here:

"importnb can run notebooks as command line scripts. Any literal variable in the notebook, may be applied as a parameter from the command line."

Mostly though it is sort of the opposite of where your focus seems to be.

Upvotes: 1

Related Questions