Comments on: lxml vs. ElementTree

By: Lala

Lala — Thu, 29 Mar 2012 12:20:00 +0000

Also a comparison of the memory consumption for parsing large XML-Strings would be interesting to see for the 3 candidates.

By: Valery

Valery — Wed, 02 Mar 2011 13:03:43 +0000

hi, great post.

what about lxml.html?
what implementation is used behind it?
is it possible to ensure that C-implementation is used?

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.