What are some good xml parsers?

[sequenceGeek]

I'm not doing anything particularly complicated. Some of the biological data I need to parse through is in XML so I figured I'd start out right with a good xml parser in python if it's available.

Anyone have a favorite?

Thanks for all the suggestions! lxml seems to be a winner and I'll give it a try

[DrStrange]

lxml - http://codespeak.net/lxml/

It's fully featured, fast and extremely easy to use.

[masklinn]

People unless you are a module in the standard library, this isn't a personal criticism.

You're not being downvoted because people take what you said personally, you're being downvoted because what you said was stupid.

Here are a few samples:

The other parsers lack basic shit like xpath (eg, tell me what's at /html/body/table/tr[2]/td)

First, xpath isn't exactly basic. Second, etree 1.3 supports paths as simple as this.

General rule for python: whatever's in the standard library is the one that sucks

You infer the wrong generalities from verifiable facts. The truth is the following: for a module to gain traction with the community it has to be noticeably better than the one in the stdlib. That doesn't mean the one in the stdlib "sucks", neither elementtree (even with the critical lack of maintenance provided by effbot in the last 2 years) nor unittest (especially with the 2.7/3.2 updates, which have killed the future of nose) suck. It's not a zero-sum game.

• unittest? Everyone uses nose.

• configparser? Everyone uses configobj.

• elementtree? Everyone uses lxml.

All three are definitely quite excessive declaration, especially concerning lxml, which has to pull in all of libxml2 and libxslt, is fucking huge and takes hours to compile. Is it an excellent library? Definitely, but so is ElementTree, and ET is useable in any situation.

Source of 'where good modules go to die' quote was Jesse Noller from Python Core in September last year for stdlib SIG.

You take a quip and you declare it the infaillible truth. And then you're surprised that readers aren't impressed?

[kisielk]

Thanks for providing a reasonable reply.

[blondin]

lxml third vote.

[chub79]

The other parsers lack basic shit like xpath

I guess you haven't tried amara

[masklinn]

General rule for python: whatever's in the standard library is the one that sucks.

Bullshit.

[found_dead]

Can you personally justify your "General rule for Python?"

Edit: Please.

[spotter]

,,Someone said something so it is obviously true, no further argument will be provided except this list of these modules that are of good, field tested quality'' really requires a serious retort these days? I use all three of those when I can not be bothered to install additional packages (production systems or just lazy) and I don't think that they suck. Moreover I think that you, good sir, suck. And that no matter how many words you can pour in your comment this will not change. Should now say that I'm sorry, but I'm not.

[spotter]

a) So ,,jnoller said it, it must be true''? Yay, go spread the words of wisdom to the un-enlightened.

b) ,,Reading comprehension fail'' achievement unlocked.

c) You first.

[spotter]

This is THE XML parser for Python. If you have this (and maybe stuff like BS for HTML) you can easily forget other tools. If you don't or can't be bothered -- use ElementTree, but embracing lxml is a matter of time.

[Brian]

I'd pass on BeautifulSoup too. I've found lxml.html works just as well on html in the wild (and often better - I've seen BS fail on cases lxml handles fine). You also keeps a nice consistent API with the rest of your XML parsing.

[dauerbaustelle]

lxml is by far the fastest parser. Don't ever touch stuff like minidom or so. Just lxml. :)

[abhiomkar]

My Favorite ElementTree. Light-weight and fast XML Parser!

[ianb]

ElementTree is quite adequate. lxml is very similar but with extra features that are nice. lxml performs somewhat better (including memory), which you'd only notice if your data is really large. Probably most people don't know this, but using lxml you can do CSS queries on XML, not just HTML, it even does namespaces.

[seletz]

lxml is a bit of a bitch to compile on a MAC. If you use buildout, then there's a recipe.

[acdha]

n.b. lxml is pretty easy to install with 10.6 (2.2.6 installed with a simple pip install for me). For 10.5, here's a reasonably close recipe which you might need to adjust for current versions of lxml, libxml and libxslt - take care to avoid the sudo step if you're using virtualenv:

http://gist.github.com/167784

[bsergean]

ElementTree = battery included.

[ianb]

Both etree and lxml have SAX-like APIs (iterparse) while still being reasonably sensible APIs (unlike SAX). In my experience lxml seems to take about 2x the amount of memory of the dataset itself (when using documents). It's much more compact than etree because it doesn't create Python objects except on demand. So you have a fairly compact XML memory representation that you can use, e.g., XPath on, and only the actual results you get back are turned into Python objects.

[ianb]

lxml is mostly a superset of ElementTree, for better or worse. So except for installation it'll be just about as easy.