Comments on: lxml vs. ElementTree

By: Marius Gedminas

Marius Gedminas — Sat, 17 Oct 2009 22:26:06 +0000

Every time I see a table of numbers in a blog post I wish the author used something like Google Charts to make a pretty picture.

By: Michael Schurter

Michael Schurter — Fri, 16 Oct 2009 03:01:14 +0000

Enumerating every feature lxml has that ElementTree lacks would take some time, but thanks for trying Jon. IIRC XML Schema support is incomplete, but don’t quote me on that as I’ve never used it.

Feature-wise lxml definitely wins, but lxml even improves the standard ElementTree interface with features such as iterating all descendants of an element easily and parent node traversal (instead of just forward/child traversal).

CSS selectors are my favorite lxml feature, and for the jQuery enthusiast, pyquery is a dream come true: it builds a jQuery-like interface on top of lxml.

Thanks for the comments all!

By: Jon

Jon — Fri, 16 Oct 2009 01:28:34 +0000

Don’t forget that lxml also supplies XML Schema, RELAX-NG, DTD, and Schematron validation.

By: mike bayer

mike bayer — Thu, 15 Oct 2009 23:54:48 +0000

the big win of lxml is that you can actually get at the DOCTYPE node using the native API. cElementTree has no way of doing this (you have to write a custom subclass using ElementTree). looking at the source you can see it just throws DOCTYPE away. Why this node wouldn’t be considered important is beyond me.

my general impression is that lxml is much more actively maintained.

By: Marcin

Marcin — Thu, 15 Oct 2009 13:33:18 +0000

Hmm, now I’m starting to wonder if using lxml in my tools that read XML is going to be of any benefit over cElementTree. I read XML for configuration and read XML generated by other systems/tools. Sticking with cetree, would be better for compatibility/portability since it is (part) of the standard lib. I guess I’m going to have to benchmark this on my own and find out. Thanks for posting this!

By: Michael Schurter

Michael Schurter — Thu, 15 Oct 2009 00:21:07 +0000

@Jon:

Only those first 4 columns (with the 3rd being the most important as an aggregate of the first 2) are the only ones generated using what I would consider a real world use case.

Those show lxml to be a very clear winner at XML generation which lxml’s benchmarks have already shown.

The last couple columns are the most interesting as they show lxml and etree being awfully similar for parsing XML which isn’t what lxml’s benchmarks say. Unfortunately my parsing tests are nearly worthless and not at all real world unless you’re opening XML files to read out single values.

I hope this post is still interesting and not misleading.