[IPython-dev] Re: Changes to Notebook Format

Toni Alatalo antont at an.org
Fri Jul 22 09:05:33 CDT 2005


Robert Kern wrote:

> Tzanko Matev wrote:
>
>> <element id="1">
>> <input type="normal">
>> def foo(x, y):
>>     return x + y
>> </input>
>> </element>
>
> In trying to convert some code to this scheme, I'm finding that it's 
> rather cumbersome. Since the number is attached to the ancestor of 
> <input> and <output>, I can't just get all normal inputs or all 
> special inputs. Nor can I easily tell when a an particular entry also 
> has a special input. For example, 

hm.

> when I want to export the plain code, I used to use a single XPath 
> expression to get all normal inputs and another XPath expression to 
> all special inputs, which I stick in a dictionary keyed by the number. 
> Then I go through the normal inputs and replace them with the special 
> inputs if they are in the dictionary. With the above scheme, I iterate 
> over the <cell> elements (I changed <element> to <cell>), check for 
> the presence of a special input with an XPath expression, use it if 
> found or if not, then I get the normal input with an XPath expression. 
> That's not ideal.

thanks for writing up this info on needed operations, btw.

> Can you describe the operations that you need to do? How often do you 
> have to access this data such that XPath is observably too slow? I 
> think it's probable that this rearrangement may *increase* the number 
> of XPath expressions you need to evaluate.

any info on how this is turning out?

i suppose this is not a case of "using xml to solve a problem? now you 
have two problems.." like the saying goes. yet i wonder, would this be 
different for you if we were talking about Python? (dunno if the 
question really warrants an answer)

as already told in a private message for the mentors, i'm off-line next 
week - back to work on this after that, looking forward to looking into 
these issues then.

~Toni

BTW, if i may suggest a style issue: the nbshell code seems to include 
'getters' that would be naturally properties in current Python (they 
came already in 2.2 so no version prob.), e.g. these in PythonPluginFactory:

   def GetString(self):
        """ Returns the type string of the plugin. This is used when a 
notebook
        file is loaded. See notebookformat.txt for more info"""
        return "python"
   
    def GetType(self):
        """ Returns the way data should be passed to the plugin. Currently
        supported types are "raw" and "encoded". See notebookformat.txt for
        more info"""
        return "raw" #Probably only the python code plugin should be raw

those are currently unnecessary, but could be just .string and .type (or 
perhaps .type and .input_type?). then later if they need to wrapped to 
some method just make them properties ( 
http://www.python.org/2.2/descrintro.html#property ).

in one other project i've tried using properties even for something 
really dynamic, in fact for an exactly similar thing as this in 
ipnDocument.py:

    def IsModified(self):
        """returns if the file has been modified since last save"""
        #TODO: Right now there is no point in doing anything useful
        #here. When things are done fix it
        return True

there am using a property called 'changed', which has such a getter that 
it resets the change flag in the object. so this 'IsModified()' might 
also be better just as a property called 'modified', but that is already 
a bit more controversial issue (as ppl are perhaps used to such dynamic 
things being exposed as methods?)




More information about the IPython-dev mailing list