473,233 Members | 1,559 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,233 software developers and data experts.

ElementTree should parse string and file in teh same way

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;
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.
Dec 31 '07 #1
11 3474
On Dec 31, 3:42 am, "Peter Pei" <yan...@telus.comwrote:
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;
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.
I haven't tried this, but you should be able to wrap your text string
so that it looks like a file using the stringio module and pass that
to elementtree:

http://blog.doughellmann.com/2007/04...cstringio.html

- Paddy.
Dec 31 '07 #2
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
Dec 31 '07 #3
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" <st******************@web.dewrote in message
news:47**************@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
Jan 1 '08 #4
To be preise, XPath is not fully supported. Don't be a smart asshole.
================================================== ===================
"Stefan Behnel" <st******************@web.dewrote in message
news:47**************@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
Jan 1 '08 #5
On Tue, 01 Jan 2008 01:53:47 +0000, Peter Pei wrote:
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.
Oh my, somebody decided to start the new year with all guns blazing.

Before abusing anyone else, have you considered asking *why* ElementTree
does not treat files and strings the same way? I believe the writer of
ElementTree, Fredrik Lundh, frequents this newsgroup.

It may be that Fredrik doesn't agree with you that you should be able to
parse a string and a file the same way, in which case there's nothing you
can do but work around it. On the other hand, perhaps he just hasn't had
a chance to implement that functionality, and would welcome a patch.

Fredrik, if you're reading this, I'm curious what your reason is. I don't
have an opinion on whether you should or shouldn't treat files and
strings the same way. Over to you...

--
Steven
Jan 1 '08 #6
Peter Pei wrote:
To be preise
[...]

Preise the lord, not me. :)

Happy New Year!

Stefan
Jan 1 '08 #7
On Tue, 01 Jan 2008 13:36:57 +0100, Diez B. Roggisch wrote:
And codemonkeys know that in python

doc = et.parse(StringIO(string))

is just one import away
Yes, but to play devil's advocate for a moment,

doc = et.parse(string_or_file)

would be even simpler.

Is there any reason why it should not behave that way? It could be as
simple as adding a couple of lines to the parse method:

if isinstance(arg, str):
import StringIO
arg = StringIO(arg)

I'm not saying it *should*, I'm asking if there's a reason it *shouldn't*.

"I find it aesthetically distasteful" would be a perfectly acceptable
answer -- not one I would agree with, but I could accept it.

--
Steven
Jan 1 '08 #8
Steven D'Aprano wrote:
On Tue, 01 Jan 2008 13:36:57 +0100, Diez B. Roggisch wrote:
>And codemonkeys know that in python

doc = et.parse(StringIO(string))

is just one import away

Yes, but to play devil's advocate for a moment,

doc = et.parse(string_or_file)

would be even simpler.
I assume the problem with this is that it would be ambiguous. You can
already use either a string or a file with ``et.parse``. A string is
interpreted as a file name, while a file object is used directly.

How would you differentiate between a string that's supposed to be a
file name, and a string that's supposed to be XML?

Steve
Jan 1 '08 #9
On Tue, 01 Jan 2008 12:59:44 -0700, Steven Bethard wrote:
Steven D'Aprano wrote:
>On Tue, 01 Jan 2008 13:36:57 +0100, Diez B. Roggisch wrote:
>>And codemonkeys know that in python

doc = et.parse(StringIO(string))

is just one import away

Yes, but to play devil's advocate for a moment,

doc = et.parse(string_or_file)

would be even simpler.

I assume the problem with this is that it would be ambiguous. You can
already use either a string or a file with ``et.parse``. A string is
interpreted as a file name, while a file object is used directly.
Ah! I wasn't aware that parse() operated on either an open file object or
a string file name. That's an excellent reason for not treating strings
the same as files in ElementTree.
How would you differentiate between a string that's supposed to be a
file name, and a string that's supposed to be XML?
Well, naturally I wouldn't.

I *could*, if I assumed that a multi-line string that started with "<"
was XML, and a single-line string with the path separator character or
ending in ".xml" was a file name, but that sort of Do What I Mean coding
is foolish in a library function that can't afford to occasionally Do The
Wrong Thing.
--
Steven
Jan 1 '08 #10
To answer something posted deep down... It is fine with me if there are two
functions - one to parse a file or file handler and one to parse a string,
yet the returned objects should be consistent.

Jan 2 '08 #11
Steven D'Aprano wrote:
Fredrik, if you're reading this, I'm curious what your reason is. I don't
have an opinion on whether you should or shouldn't treat files and
strings the same way. Over to you...
as Diez shows, it's all about use cases.

and as anyone who's used my libraries or read my code knows, I'm a big
fan of minimalistic but highly composable object API:s and liberal use
of short helper functions to wire them up to fit the task at hand.

kitchen sink API design is a really bad idea, for more reasons than I
can fit in this small editor window.

</F>

Jan 2 '08 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Stewart Midwinter | last post by:
I want to parse a file with ElementTree. My file has the following format: <!-- file population.xml --> <?xml version='1.0' encoding='utf-8'?> <population> <person><name="joe" sex="male"...
1
by: Greg Wilson | last post by:
I'm trying to convert from minidom to ElementTree for handling XML, and am having trouble with entities in DTDs. My Python script looks like this: ...
4
by: alainpoint | last post by:
Hello, I use Elementtree to parse an elementary SVG file (in fact, it is one of the examples in the "SVG essentials" book). More precisely, it is the fig0201.svg file in the second chapter. The...
3
by: mirandacascade | last post by:
Verion of Python: 2.4 O/S: Windows XP ElementTree resides in the c:\python24\lib\site-packages\elementtree\ folder When a string that does not contain well-formed XML is passed as an argument...
15
by: Steven Bethard | last post by:
I'm having trouble using elementtree with an XML file that has some gbk-encoded text. (I can't read Chinese, so I'm taking their word for it that it's gbk-encoded.) I always have trouble with...
0
by: Greg Aumann | last post by:
I am trying to write some python code for a library that reads an XML-like language from a file into elementtree data structures. Then I want to be able to read and/or modify the structure and then...
2
by: rajarshi.guha | last post by:
Hi, recently having discovered ElementTree I'm stumped by a very simple problem, which I can't find the answer to. I have some XML in a string object. Now the parse() method of ElementTree takes...
6
by: Sébastien Boisgérault | last post by:
I guess I am doing something wrong ... Any clue ? Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/elementtree/ElementTree.py", line 960,...
2
by: =?ISO-8859-1?Q?J=2E_Pablo_Fern=E1ndez?= | last post by:
Hello, Is ElementTree supposed to load DTDs? I have some xmls heavy on entities and it fails this way: Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42) on linux2 Type "help", "copyright",...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.