ANN: ElementTree 1.2 final (june 18, 2004)

[François Pinard]

[Edward C. Jones]

> I would like to suggest some additions to Element:

> walk: A generator that walks a tree in depth-first order. I think this
> is the same as "getiterator" but the docs are confusing.

There are many ways to do this walking already.  As you mention,
getiterator() without a tag argument, but also -- according to
the documentation -- getchildren(), and maybe findall('.//*').
One could easily write its own walker, with variations.

> reverse_walk: Like walk but in the reverse order.

This is probably not as often needed.  I guess one could use
getchildren() and reverse the resulting list.  Here again, one could
easily write its own walker.

> walkaround: Walks around the outside of a tree. Each non-terminal node
> is visited twice. Each node should have a attribute whose values can
> be NONE, DONE, FIRST, SECOND, and LEAF.

It might be easier that one writes its own walker than to add and remove
artificial attributes from nodes.  A terminal node is fairly easy to
recognise in Python: the node evaluates to False in boolean context.

> kill: Removes a node from a tree. It is replaced by its children.

`elementtree' allows getting and setting slices of children on nodes,
using the Python notation for slices.  This should be sufficient for
operations like the above.  This could be combined with the clear()
method if it fits.

One thing that `elementtree' does not provide is the parent element of
a given element, something which might be useful when one wants to kill
a node per your definition above.  If I had such a frequent need, I
would probably attempting walk an XML-tree for adding parent information
everywhere first (hoping Element class does not use `__slots__').

> prettyprint: Prints a tree with each node indented according to its
> depth.

If you do not consider text nor attributes, this is pretty trivial to
write.  The usual problem is how to pretty print a tree when there
are attributes and long texts intermixed; each user would then have
preferences or per-application desires.

All this to say that it is not easy, and probably not wise, trying to
list "common" operations and specifying them in such a way they will
please everybody.  I like the `elementtree' approach, which avoids
any flurry of methods, but well tie with the Python language itself,
allowing users to easily "complete" `elementtree' according to their
per-application wishes, and using very natural Python idioms to do so.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard