minidom already has something like this:

http://docs.python.org/3/library/xml.dom.minidom.html#xml.dom.minidom.Node.toprettyxml

This is something that appears to have almost made it in quite a while ago:

http://effbot.org/zone/element-lib.htm#prettyprint
http://svn.effbot.org/public/stuff/sandbox/elementlib/indent.py

A casual search found several similar implementations out there.  For instance:

http://infix.se/2007/02/06/gentlemen-indent-your-xml

I have attached a proposed patch.

This makes some design decisions which I would like someone to review:
 a) To incorporate pretty-printing into the main write() method rather than adding a separate toprettyxml() method. Disadvantages: greater complexity of _serialize_xml(). Advantages: Reduced duplication of code, easy to add other pretty-printing (eg HTML) in the same way.
 b) Existing whitespace on the ends of existing text is mutated. Disadvantages: existing whitespace content may get changed. Advantages: Greater readability (which is the whole point), idempotence of pretty-printing.
 c) Not to add a trailing newline. I am undecided as to whether this is a bad idea or a good one, but am documenting it to ensure it gets visibility.

Of these, I think b) is the only potentially controversial one, and notably its behaviour differs from minidom's toprettyxml. I think it's the right thing to do though; and for the cases where whitespace is important, perhaps we can respect the xml:space attribute when pretty-printing?
http://www.w3.org/TR/xml/#sec-white-space

If these design choices are deemed suitable I'm happy to update the patch to support pretty-printing HTML also.

One other design decision - currently it doesn't deal with the indentation of comments or processing instructions: it leaves them unindented. Should they be indented the same as other tags?

Thanks for the report (Eric) and the patch (Alex). There are currently some open bugs we need to handle first, so this is somewhat lower priority. I hope to get to it before the 3.4 release.

I've noticed this is a duplicate of issue #14465. Closing it - let's continue the discussion there, when the time comes.

This has just made me switching away from xml.etree.ElementTree today, sadly.

What a pity; it would have been all kind of cool to stick to this minimal, otherwise working parser and builder.