ElementTree should parse string and file in the same way
yantao at telus.com
Tue Jan 1 02:53:47 CET 2008
You are talking shit. It is never about whether it is hard to write a
wrapper. It is about bad design. I should be able to parse a string and a
file in exactly same way, and that should be provided as part of the
Looks like you are just a code monkey not a designer, so I forgive you. You
didn't understand the issue I described? That's your issue. You are not at
the same level to talk to me, so chill.
"Stefan Behnel" <stefan.behnel-n05pAM at web.de> wrote in message
news:4778A47B.9020201 at web.de...
> Peter Pei wrote:
>> One bad design about elementtree is that it has different ways parsing a
>> string and a file, even worse they return different objects:
>> 1) When you parse a file, you can simply call parse, which returns a
>> elementtree, on which you can then apply xpath;
> ElementTree doesn't support XPath. In case you mean the simpler
> language that is supported by the find*() methods, I do not see a reason
> you can't use it on elements.
>> 2) To parse a string (xml section), you can call XML or fromstring, but
>> both return element instead of elementtree. This alone is bad. To make
>> it worse, you have to create an elementtree from this element before you
>> can utilize xpath.
> a) how hard is it to write a wrapper function around fromstring() that
> the result Element in an ElementTree object and returns it?
> b) the same as above applies: I can't see the problem you are talking
More information about the Python-list