Introduction

Fredrik Lundh's ElementTree module is an increasingly popular API for light-weight and fast manipulation of XML documents within Python. In this installment, David contrasts ElementTree with several other libraries devoted to processing XML instances as object trees, especially with his own gnosis.xml.objectify module. You can share your thoughts on this article with the author and other readers in the accompanying discussion forum.

In previous installments of this column, I have looked at XML libraries whose aim is to emulate the most familiar native operations in a given programming language. The first of these that I covered is my own gnosis.xml.objectify for Python. I also dedicated installments to Haskell's HaXml and Ruby's REXML. Although I have not discussed them here, Java's JDOM and Perl's XML::Grove also have similar goals.

Lately, I have noticed a number of posters to the comp.lang.python newsgroup mentioning Fredrik Lundh's ElementTree as a native XML library for Python. Of course, Python already has several XML API's included in its standard distribution: a DOM module, a SAX module, an expat wrapper, and the deprecated xmllib. Of these, only xml.dom converts an XML document into an in-memory object that you can manipulate with method calls on nodes. Actually, you'll find several different Python DOM implementations, each with somewhat different properties:

• xml.minidom is a basic one.
• xml.pulldom builds accessed subtrees only as needed.
• 4Suite's cDomlette (Ft.Xml.Domlette) builds a DOM tree in C, avoiding Python callbacks for speed.

Of course, appealing to my author's vanity, I am most curious to compare ElementTree to my own gnosis.xml.objectify, to which it is closest in purpose and behavior. The goal of ElementTree is to store representations of XML documents in data structures that behave in much the way you think about data in Python. The focus here is on programming in Python, not on adapting your programming style to XML.