homepage

I often miss lxml's "pretty_print=True" functionality. Can you implement something similar.

Would you like to provide a patch?

Tshepang,
Frankly, there are a lot of issues to solve in ElementTree (it hasn't been given love in a long time...) and such features would be low priority, as I'm not getting much help and am swamped already.
As Martin said, patches can go a long way here...

Okay, I will try, even though C scares me.

You may be able to code it entirely in the Python part of the module (adding a new parameter to Element.write and tostring).

A patch exists in the duplicate #17372 

Proposed patch copied over from duplicate issue 17372.

Just to reiterate this point, lxml.etree supports a "pretty_print" flag in its tostring() function and ElementTree.write(). It would thus make sense to support the same thing in ET.
http://lxml.de/api.html#serialisation
For completeness, the current signature looks like this:
def tostring(element_or_tree, *, encoding=None, method="xml",
 xml_declaration=None, pretty_print=False,
 with_tail=True, standalone=None, doctype=None,
 exclusive=False, with_comments=True,
 inclusive_ns_prefixes=None):
(The last three options are for C14N serialisation.)

For the record, at 2015年04月02日, the bpo-23847 has been marked as a duplicate of this issue.

My thoughts:
1. Whitespaces are significant in XML. Pretty-printed XML is different from the original XML to an XML parser. For some applications some whitespaces around tags are not significant. But this depends on the application and in different parts of the document whitespaces can have different meaning. For example the document can contain a metadata with insignificant whitespaces and marked up text with significant whitespaces. There is a special attribute named xml:space that can signal the meaning of whitespaces for the part of a document.
https://www.w3.org/TR/xml/#sec-white-space
2. In HTML whitespaces around <P> are insignificant, but whitespaces around <I> are significant. Whitespaces inside <PRE>...</PRE> are significant.
3. If strip whitespaces around tags and insert newlines and indentations, shouldn't we strip whitespaces inside the text context? Or preserve newlines but update indentations?
4. If modify whitespaces on output, it may be worth to add an option to ignore insignificant whitespaces on input.
5. Serialization of ElementTree in the stdlib is much slower than in lxml (see issue25881). Perhaps it should be implemented in C. But it should be kept simple for this. Pretty-printing can be implemented as an outher preprocessing operation (for example the original Eli's code indents the tree in-place: http://effbot.org/zone/element-lib.htm#prettyprint) or as a proxy that indents elements on-fly.

> Serialization of ElementTree in the stdlib is much slower than in lxml (see issue25881). Perhaps it should be implemented in C. But it should be kept simple for this.
Should I say it? That's a first class use case for Cython.
> Pretty-printing can be implemented as an outher preprocessing operation
Agreed. And that would actually be much simpler to implement in C.

A few more thoughts for consideration:
* We already have a toprettyxml() tool in the minidom package.
* Since whitespace is significant in XML, prettifying changes the content and meaning, so it doesn't round-trip and should only be used for debugging purposes.
* Usually, I recommend using XML viewers such as the one built into the Chrome browser. That provides indentation without changing meaning. It also lets you run searches and conveniently supports folding and unfolding elements. I would rather someone use a viewer rather than something like toprettyxml().

I have a use case where the receiving application is expecting the indentation, and I need to run my code in Lambda. So, lxml is out of the question.

FWIW, here is the relevant section of the XML specification, https://www.w3.org/TR/2008/REC-xml-20081126/#sec-white-space :
"""In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.
An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content.
"""
OTOH, the java TransformerFactory does support a property, OutputKeys.INDENT, so there is a precedent for this feature request.
Stefan, would you please make a final determination or pronouncement on whether this makes sense for ElementTree or whether it is outside the scope of what the module is trying to accomplish.

The spec section that Raymond quoted makes it clear that pretty printing is not for everyone. But there are many use cases where it is 1) helpful, 2) leads to correct results, and 3) does not grow the file size excessively. Whoever wants to make use of it is probably in such a situation. I think adding some kind of support in the standard library would be nice, but it should not hurt "normal" uses, especially when a lot of data is involved.
I'll send a PR that adds an indent() function to pre-process trees. Comments welcome.

New changeset b5d3ceea48c181b3e2c6c67424317afed606bd39 by Stefan Behnel in branch 'master':
bpo-14465: Add an indent() function to xml.etree.ElementTree to pretty-print XML trees (GH-15200)
https://github.com/python/cpython/commit/b5d3ceea48c181b3e2c6c67424317afed606bd39