[IPython-dev] Re: [FWD] Re: Re: Changes to Notebook Format

Robert Kern rkern at ucsd.edu
Mon Jul 18 12:02:47 CDT 2005


Fernando Perez wrote:
> [Toni, I've added you to the whitelist, but if you use multiple email 
> aliases, remember that the ipython lists discard non-subscriber posts]
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [IPython-dev] Re: Changes to Notebook Format
> From:
> Toni Alatalo <antont at kyperjokki.fi>
> Date:
> Mon, 18 Jul 2005 14:36:32 +0300 (EEST)
> To:
> ipython-dev at scipy.net
> 
> To:
> ipython-dev at scipy.net
> 
> On Mon, 18 Jul 2005, Robert Kern wrote:
> 
>>><ipython-log logid="default-log">
>>><element id="1">
>>
>>As a sidenote: conventionally, the "id" attribute on any tag must be 
>>unique document-wide, so we'll stick with "number" here.
> 
> ok.
> 
>>>The input tags can have types "normal" and "special" which correspond to
>>>the tags <input> and <special-input> of the current format. The output
>>>tags can have types "normal", "stdout", "figure", etc. One input tag can
>>>have several corresponding output tags with different types.
>>
>>Every "special" input will also have a "normal" input that keeps the 
>>transformed-into-valid-Python command, too.
> 
> hm didn't get all of this yet but ok i guess.

When one does a "special" input (a %magic, a !system command, etc.), 
IPython will transform it to valid Python, either to a method invocation 
on the interpreter object or to a comment. I think we need to store both 
because the transformation may be dependent on what has previously been 
executed.

>>>that the resulting ElementTree object would be more useful that way. In
>>>order to parse a file of the current format I need to create its
>>>corresponding ElementTree object and then I must make my own data
>>>representation from that object, because searching for tags with XPath
>>>is slow and with the current format there is no easier way to retrieve
>>>the text I need. With the proposed format I don't really need another
>>>internal data rpresentation, which would make my code cleaner.
> 
> i definitely agree that you should not have to do any parsing / 
> structuring of the data for the GUI work -- it's my task to keep the 
> underlying lib in such a shape that it facilitates your work (of course we 
> don't have to keep this separation artificially strict, but that's the 
> idea in principle, right?)
> 
> so please voice out all the demands for the API - like methods you'd like 
> to have for the notebook objects etc.
> 
>>are two different operations. One might want to perform the former but 
>>not the latter if one references In[NN] or Out[NN].
>>But that may be something we can worry about later.
> 
> ok
> 
>>Robert Kern
> 
> btw Robert, did you implement / plan to implement those changes already, 
> or would it be for me to do? a chance to get it going with your codebase, 
> perhaps..

http://ipython.scipy.org/svn/ipython/google-rkern/branches/cell

I resolved my issues by making a Cell object that takes the element and 
assigns the contents of its children to Python attributes. I've left the 
figures out of the cells because they have a somewhat different 
structure. We can change that later when we start doing images in the 
GUI and think that it's necessary.

Also, check out the sample output in the test/ directory.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter




More information about the IPython-dev mailing list