[IPython-dev] Re: Changes to Notebook Format
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
> 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,
> 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.
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:
""" Returns the type string of the plugin. This is used when a
file is loaded. See notebookformat.txt for more info"""
""" Returns the way data should be passed to the plugin. Currently
supported types are "raw" and "encoded". See notebookformat.txt for
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 (
in one other project i've tried using properties even for something
really dynamic, in fact for an exactly similar thing as this in
"""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
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