It is possible to create and serialize an Element instance with empty string tag value:

>>> import xml.etree.ElementTree as etree
>>>
>>> root = etree.Element('')
>>> elem = etree.SubElement(root, '')
>>>
>>> root
<Element '' at 0xb744e34c>
>>> elem
<Element '' at 0xb744e374>
>>>
>>> etree.tostring(root)
b'<>< /></>'
>>> etree.dump(root)
<>< /></>
>>>


It is possible to create and serialize an Element instance with None tag value:

>>> import xml.etree.ElementTree as etree
>>>
>>> root = etree.Element(None)
>>> elem = etree.SubElement(root, None)
>>>
>>> root
<Element None at 0xb7468c34>
>>> root[0]
<Element None at 0xb746334c>
>>> len(root)
1
>>> etree.tostring(root)
b''
>>> etree.dump(root)

>>>


And same try with site package lxml raises an exception both for empty string and for None:

>>> import lxml.etree
>>>
>>> lxml.etree.Element('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lxml.etree.pyx", line 2809, in lxml.etree.Element (src/lxml/lxml.etree.c:61393)
  File "apihelpers.pxi", line 87, in lxml.etree._makeElement (src/lxml/lxml.etree.c:13390)
  File "apihelpers.pxi", line 1446, in lxml.etree._getNsTag (src/lxml/lxml.etree.c:25978)
  File "apihelpers.pxi", line 1481, in lxml.etree.__getNsTag (src/lxml/lxml.etree.c:26304)
ValueError: Empty tag name
>>>
>>> lxml.etree.Element(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lxml.etree.pyx", line 2809, in lxml.etree.Element (src/lxml/lxml.etree.c:61393)
  File "apihelpers.pxi", line 87, in lxml.etree._makeElement (src/lxml/lxml.etree.c:13390)
  File "apihelpers.pxi", line 1446, in lxml.etree._getNsTag (src/lxml/lxml.etree.c:25978)
  File "apihelpers.pxi", line 1464, in lxml.etree.__getNsTag (src/lxml/lxml.etree.c:26114)
  File "apihelpers.pxi", line 1342, in lxml.etree._utf8 (src/lxml/lxml.etree.c:24770)
TypeError: Argument must be bytes or unicode, got 'NoneType'
>>>

I decided to take a look at this, since it seems easy...

At first glance, this would appear to be a straightforward change--the docs state in multiple places that Element() takes a string as its tag argument.

But it turns out that a lot of internal functionality depends on passing in non-strings as the tag value.

I don't think this is worth fixing.  The package is under no obligation to make early type checks for arguments.  It is typical in the Python world to let those kinds of input errors surface downstream when they are used.  In contrast, C code typically does the checks when the arguments are passed in.

I disagree. This library is meant to be an interface onto XML syntax, and XML has pretty strict requirements on syntax. As msg277125 shows, you're liable to get very far downstream before the error becomes apparent.

In addition, I'm finding a number of internal inconsistencies, both between the docs and the code and between the Python code and the C code, that demonstrate that doing these type checks up front would be beneficial to the entire library. (Note: The C code also does not do them.)

I concur with Raymond. Supporting non-string tags is a feature of ElementTree that is used internally (for comments, etc) and can be used in user code. And the C implementation intentionally reproduces this feature.

I also consider it an actual feature of ElementTree to allow arbitrary objects as its tags, even if it's not one of the most prominent. lxml cannot copy this because it is based on C libraries internally, but that shouldn't prevent ET from allowing it.

The fact that None tags disappear is also definitely a feature. It's an easy way to delete tags from trees without requiring any restructuring.

OTOH, whether an empty string should be serialised in the way the OP shows is not so clear. The output is not XML. I can't see any use case for this, but it feels like a potential source of bugs. I think it would be better to have the serialiser explicitly reject this than letting it silently generate broken output.

Not something to change in Py3.6, though.

To be clear, we are talking about the Element class of the ElementTree module, which is distinct from the ElementTree class of the same module.

That said, I personally question the implementation decision to represent things like treating comments as an Element with a tag of a Comment function. The XML standard is pretty clear that neither comments nor processing instructions are in fact elements, and I don't see it as a Good Thing that arbitrary objects are allowed as the value of tag, unless there is a requirement that such objects are subclasses of str.

Note also that the documentation makes no mention of tag being anything other than a string. And there is inconsistency with where bytes are supposedly allowed (according to the documentation) and where they're actually allowed (according to the code). Given this, I think it's hard to say what user code is expected to make use of.

Issues of potential relevance to this discussion:
* Issue28237 - In xml.etree.ElementTree bytes tag or attributes raises on serialization
* Issue5166 - ElementTree and minidom don't prevent creation of not well-formed XML

>That said, I personally question the implementation decision to
>represent things like treating comments as an Element with a tag of a
>Comment function. 

This is not going to change.

Marking this as closed.

Gordon, thank you for showing an interest in this tracker item.  While fixing bugs is of interest, altering long standing intentional design decisions is not useful.  The time to do that is before a module is released, not a decade later.