ElementTree should parse string and file in the same way

[Peter Pei]

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 
package.

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 
> ElementPath
> language that is supported by the find*() methods, I do not see a reason 
> why
> 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 
> wraps
> 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 
> about.
>
> Stefan