On Mon, 6 Sep 2010 10:15:25 -0700 (PDT)
"Edward K. Ream" <[email protected]> wrote:
> I contend that the new code is actually at least as easy to understand
> than the xpath code. I think it would have been just as easy to write
> the new code as it would have been to write the old code.
>
> In other words, for *this* application at least, lxml appears to add
> exactly nothing of significance to ElementTree.
Of course I disagree. I think a platform which does not provide at least
moderate support for XPath does not really support XML, at least from a DOM
perspective, which I think is the natural way to handle XML in this context
(Inkscape extensions are written in python, using the DOM model, and requiring
lxml(*)).
To put it another way, if you're writing DOM based XML code then you're
familiar with XPath and expect to be able to use it. Say, for an HTML example,
I want the captions of all the tables within the content element with headers
which mention "precipitation":
doc.xpath("//*...@id='content']//caption[..//th[contains(.,
'precipitation')]/text()")
Could you write code to find them without XPath? Of course. Should you need
to? I don't think so. You'd certainly never have to write such code in Java
:-/
(*) which makes you wonder how they distribute their extensions with the
Windows version of Inkscape. I suspect they distribute python with inkscape in
a subdirectory of the inkscape directory... :-)
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
