package similar to XML::Simple

[Paulo Pinto]

Hi,


does anyone know of a Python package that
is able to load XML like the XML::Simple
Perl package does?

For those that don't know it, this package
maps the XML file to a dictionary.

Of course I can build such a package myself
but it would be better if it already exists

 

[Pierre N]

I'm using pyRXP, and it's great.
It's using one tuple, not dictionnaries.
Very very fast.
By the way I'm just starting using this package, anybody met any
problems with pyRXP?

-- Pierre

 

[Harald Massa]

Paulo Pinto

does anyone know of a Python package that
is able to load XML like the XML::Simple
Perl package does?

Good to ask! I know of at least 3 packages that do sth. similiar.

- Fredrik Lundhs elementtree
- D. Merzs gnosis xml utilities
- handyxml

just google for them.

 

[Peter Hansen]

does anyone know of a Python package that
is able to load XML like the XML::Simple
Perl package does?

For those that don't know it, this package
maps the XML file to a dictionary.

A simple dictionary is insufficient to represent XML in general,
so perhaps you're talking about a subset of XML, maybe with no
attributes, and where the order of the child elements doesn't
matter? Or something else?

Or do you really mean something like a multiply-nested
dictionary, perhaps with lists as well?

Of course I can build such a package myself
but it would be better if it already exists

We were able to build something similar by stripping down
Fredrik Lundh's elementtree until we had little more than the
calls to the expat parser (i.e. we used his source as a tutorial
on using expat , so if this is something like the XML-subset
I mention above, you could do it in an hour or so from scratch
if you knew Python well.

-Peter

 

[Paulo Pinto]

I mean multiple nested dictionaries with lists.

But handyxml seems to solve my problem.

Thanks, guys

 

[Uche Ogbuji]

I'm using pyRXP, and it's great.
It's using one tuple, not dictionnaries.
Very very fast.
By the way I'm just starting using this package, anybody met any
problems with pyRXP?

I did. It's not an XML parser :-(. It does not accept character
entities such as … (the example that bit me), giving meaningless
"error" messages along the lines: "not a valid 8-bit XML character".
If you need an XML parser, use PyRXPU, which comes in ReportLab CVS
only. It is not as fast as PyRXP, but conformant in my testing, and
the point of XML is conformance, not speed at all costs. If you want
speed at all costs, use CSV or some other plain text format.

I'm writing at length about this unfortunate PyRXP situation in my
next ORA python/XML column (expected Weds).

--Uche
http://uche.ogbui.net

 

[Uche Ogbuji]

Hi,


does anyone know of a Python package that
is able to load XML like the XML::Simple
Perl package does?

For those that don't know it, this package
maps the XML file to a dictionary.

Of course I can build such a package myself
but it would be better if it already exists

FWIW: http://www.xml.com/pub/a/2004/01/14/py-xml.html

--Uche
http://uche.ogbui.net

 

[Peter Hansen]

I did. It's not an XML parser :-(. It does not accept character
entities such as … (the example that bit me), giving meaningless
"error" messages along the lines: "not a valid 8-bit XML character".
If you need an XML parser, use PyRXPU, which comes in ReportLab CVS
only. It is not as fast as PyRXP, but conformant in my testing, and
the point of XML is conformance, not speed at all costs. If you want
speed at all costs, use CSV or some other plain text format.

Hmm... so it's your opinion that *all* XML parsers must handle *all*
aspects of XML? If not, I think you should back off on the criticism
of PyRXP as being "not an XML parser" and simply point out that it
doesn't handle all aspects of XML because it is intended to provide
a very fast/heavily optimized approach to parsing only certain kinds
of XML. It's a valid choice to do so, though of course if PyRXP is
promoted as a "full" XML solution that might be inaccurate.

-Peter

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Hmm... so it's your opinion that *all* XML parsers must handle *all*
aspects of XML? If not, I think you should back off on the criticism
of PyRXP as being "not an XML parser" and simply point out that it
doesn't handle all aspects of XML because it is intended to provide
a very fast/heavily optimized approach to parsing only certain kinds
of XML.

I am not Uche, but I think that all XML parsers should conform to the
XML recommendation (and treat deviations from the XML recommendation
as bugs).

This is not the same as handling all aspects of XML, since the XML
recommendation makes certain aspects optional. Processing character
references is not one of them (but e.g. validation is).

It's a valid choice to do so, though of course if PyRXP is
promoted as a "full" XML solution that might be inaccurate.

Packages may help processing only selected XML documents, and they
may also support documents which are not XML. However, in neither
case, they should call themselves "XML parsers". "XML-like parsers"
or "XML subset parsers" might be more appriate.

Regards,
Martin

 

[Uche Ogbuji]

Hmm... so it's your opinion that *all* XML parsers must handle *all*
aspects of XML?

XML is clear on what a Parser *must* support. The full character
production is one of those things. From XML 1.0, section 2.2:

Character Range
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF]

There is no "option" to not support characters greater than #xFF. XML
parsers *can* leave off handling some aspects of XML, external DTD
subsets, for example, but you can not be as fundamentally
non-conformant as PyRXP and still call yourself an XML parser.

This is not just an academic matter. There are a *vast* number of
useful and heavily-used characters of code point higher than U+FF and
if parsers decided on a whim to pick and choose what to support the
result would be complete and utter chaos.

If not, I think you should back off on the criticism
of PyRXP as being "not an XML parser" and simply point out that it
doesn't handle all aspects of XML because it is intended to provide
a very fast/heavily optimized approach to parsing only certain kinds
of XML. It's a valid choice to do so, though of course if PyRXP is
promoted as a "full" XML solution that might be inaccurate.

PyRXP is not an XML parser. It's that simple. I stand by that veru
strong satement, and I'd be surprised if XML expert refusaes to
corroborate it.

I do want to point out that PyRXPU does seem to be a proper XML
parser, and is what people should use instead if they like the
ReportLab products.

Of course if yu don't really need an XML parser, feel free to use
PyRXP. Just don't call it what it isn't.

--Uche
http://uche.ogbuji.net

 

[Uche Ogbuji]

I am not Uche, but I think that all XML parsers should conform to the
XML recommendation (and treat deviations from the XML recommendation
as bugs).

This is not the same as handling all aspects of XML, since the XML
recommendation makes certain aspects optional. Processing character
references is not one of them (but e.g. validation is).


Packages may help processing only selected XML documents, and they
may also support documents which are not XML. However, in neither
case, they should call themselves "XML parsers". "XML-like parsers"
or "XML subset parsers" might be more appriate.

I wouldn't argue with calling PyRXP an "XML-like parser".

Because until very recently I thought that PyRXP was an XML parser, I
was extremely taken aback when I ran afoul of PyRXP's brazen character
non-conformance. As an example of the danger in this non-conformance,
PyRXP refused to parse the very first well-formed XML document I gave
it. And I'm (mostly) a native English speaker. True XML parsers
strive for interoperability for a reason. Not doing so pretty much
negates the value of XML.

I was even more taken aback to read that the PyRXP developers refused
to make the simple fix needed for conformance. I think it is
essential to point out that a tool that refuses XML conformance cannot
go about calling itself an XML parser.


--Uche
http://uche.ogbuji.net

 

[Peter Hansen]

I was even more taken aback to read that the PyRXP developers refused
to make the simple fix needed for conformance.

This is a very relevant data point that was missing in the discussion
until now.

Given that situation, I'd agree that labelling PyRXP simply an "XML parser"
without qualification is misleading and wrong.

-Peter

 

[Chris Herborth]

does anyone know of a Python package that
is able to load XML like the XML::Simple
Perl package does?

Despite all of the, uh, _discussion_ in this thread, I'd like to thank you
folks for pointing out pyRXP... I hadn't found that before, and if I can
whip up a pyRXP -> DOM2 translator, it will fit my needs _perfectly_.

Thanks!

 

[Paul Boddie]

Despite all of the, uh, _discussion_ in this thread, I'd like to thank you
folks for pointing out pyRXP... I hadn't found that before, and if I can
whip up a pyRXP -> DOM2 translator, it will fit my needs _perfectly_.

Well, if it is true what people claim about dictionaries and tuples
being faster than objects, then you may see any supposed performance
advantage claimed by the PyRXP proponents just dissolve away as you
instantiate all those nodes. But as I noted with respect to "double
wrapping" libxml2, if you can restrict yourself to very few high-level
operations through those layers, and then invoke various "native"
methods directly, then it could still be worth it.

Paul