As it stands in Hg, when the write() method of an xml.etree.ElementTree object is called, and a tag within the XML tree has no child tags or defined text, the tag is written using the short notation "<tag ... />".

Whether or not the short notation is used instead of the long "<tag ...></tag>" notation is used should be configurable by the programmer, without having to resort to serializing the XML into a string and then doing replace() on said string.

The attached patch adds an optional parameter to the write() method that provides this choice.
If the 'use_long_xml_tags' parameter is not set (or otherwise evaluates to the boolean False), the current behavior applies.
If this parameter evaluates to the boolean True, long tags are used when producing XML output.

-            if long_xml or text or len(elem):
+            if text or len(elem) or long_xml:

Use alternatives in order of decreasing probability.

Hello, thanks for the patch!

Since this is a new feature, I suggest discussion it on the python-ideas list first.

Next, as for your patch:

1. What is ElementTree_new.py?
2. Note that new features have to be added to in-development versions of Python - 3.3 in our case. In 3.3, the C and Python implementations of the ElementTree API must be compatible. Hence, all new features have to be added to both implementations.

To answer eli.bendersky's questions:

1. That's just the name of the file with my changes in it.
I pulled the original file from Hg, copied it to "ElementTree_new.py", made my changes, and created a patch from the two.

2. I'm not very familiar with the structure of the codebase for Python, so I'll provide some information that sounds relevant to me...

The changes I made were for the ElementTree.py file under cpython/Lib/xml/etree/ .
I used http://hg.python.org/cpython/file/54055646fd1f/Lib/xml/etree/ElementTree.py as the base to make a new patch, reflecting storchaka's recommendation on logic order and a clarification on path name for the modified file.

The source for the 'ElementC14N' module is not part of Python, so I cannot modify the code for the '_serialize_c14n' function.
It appears that this is dependent on http://bugs.python.org/issue13611 .

Looks like I may need to refactor this patch to work in a way that does not alter the signature for the _serialize_* methods.

Any progress, or can this issue be closed?

Made a new patch.
This one contains changes for xml.etree.ElementTree for cpython, jython, and stackless.
It also contains changes to Modules/_elementtree.c for cpython and stackless.

The changes within this patch do not change the signature for the _serialize_* methods, so it can be used with any third-party library that extends ElementTree.

I don't think that the three new fields in each Element is a suitable price for this very rare used feature.

Agree with Serhiy. Why are these flags required in Element?

Also, I'm moving this to 3.4 since the patch came too late in the 3.3 process - the first beta is very soon, after which we prefer not to add new features.

xml.sax.saxutils.XMLGenerator constructor has a parameter short_empty_elements (False by default). For consistency new ElementTree.write parameter must have the same name (True by default for compatibility).

Ideally, this would be taken care by the _serialize_xml() with a parameter specified when called from within write().

However, the signature for the _serialize_xml() function cannot be changed, as it needs to match the signature for the rest of the _serialize_*() functions (since which serializing function is chosen from a dictionary that then calls the specific function using the same parameters.

An alternative to this would be to create a single variable within the scope of ElementTree at runtime if the code calls to write out the full tags closing, and have the _serialize_xml() function check for the presence and value of that variable.

I initially approached the problem via the flags on Element instead due to the perceived usefulness of giving the programmer full control on how the tree is serialized into XML.

However, if I'm the only one that sees that as useful, I can certainly refactor the code to go with the above solution (or some other more elegant solution).

I see no harm in modifying the signature of the private _serialize_* functions to accept another argument or dict of options.

Ariel, are you interested in pursuing this issue?

Serhiy, I see you assigned this to yourself - would you like to submit a patch?

> Serhiy, I see you assigned this to yourself - would you like to submit a patch?

Not right now. This is low priority for me too. But I want to see this feature in 3.4.

Well, here is a patch which add short_empty_elements flag (as for XMLGenerator) to write(), tostring() and tostringlist() methods of ElementTree.

Patch updated (tostring() and tostringlist() refet to write() about short_empty_elements parameter). Perhaps descriptions of encoding and method parameters should not be repeated too?

> Why do you force short_empty_elements to be keyword only?

Because sequences of parameters in XMLGenerator(), ElementTree.write(), ElementTree.tostring() are different and this can confuse. Also it will be easer to deprecate or rename keyword-only parameter in future (in favor of general fabric for example). I think that all optional, non-basic and very rarely used parameters should by keyword-only.

New changeset 58168d69b496 by Eli Bendersky in branch 'default':
Close #14377: Add a new parameter to ElementTree.write and some module-level
http://hg.python.org/cpython/rev/58168d69b496

I don’t think a space before the slash should be added.  (It was common in the days of XHTML 1 because of an SGML parsing hack.)

On Sun, Jan 13, 2013 at 6:09 AM, Éric Araujo <report@bugs.python.org> wrote:

>
> Éric Araujo added the comment:
>
> I don’t think a space before the slash should be added.  (It was common in
> the days of XHTML 1 because of an SGML parsing hack.)
>

Ok, will fix.

I think Éric means different spaces, spaces in empty tags (<empty /> vs <empty/>). I don't know what the standard says about this. It should a separated issue.

As for line continuations in docs, in all cases where they are occurred, a space used before a backslash for readability. I have reverted this change in 50606131a987.

OK, thanks.