Observe:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> root = ET.Element('root', attrib={'Name':'Root'})
>>> child = ET.SubElement(root, 'child', attrib={'Name':'Child'})
>>> ET.tostring(root)
'<root Name="Root"><child Name="Child" /></root>'


>>> import xml.etree.cElementTree as cET
>>> root = cET.Element('root', attrib={'Name':'Root'})
>>> child = cET.SubElement(root, 'child', attrib={'Name':'Child'})
>>> cET.tostring(root)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1126, in tostring
    ElementTree(element).write(file, encoding, method=method)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 820, in write
    serialize(write, self._root, encoding, qnames, namespaces)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 932, in _serialize_xml
    v = _escape_attrib(v, encoding)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1092, in _escape_attrib
    _raise_serialization_error(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1052, in _raise_serialization_error
    "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize {'Name': 'Root'} (type dict)

Or, more succintly:


Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> root = ET.Element('Root', attrib={'Name':'Root'})
>>> root.attrib
{'Name': 'Root'}



>>> import xml.etree.cElementTree as cET
>>> root = cET.Element('Root', attrib={'Name':'Root'})
>>> root.attrib
{'attrib': {'Name': 'Root'}}

Works for me in 3.2 and 3.4, fails in 2.7, as reported.

I'll leave it to Eli to decide if this should get fixed in 2.7. In Py2, ET and cET were different modules, so this could also be considered a missing feature in cET. Given that it leads to a serialisation failure, though, it shouldn't hurt to change the behaviour.

(changing title to something more specific)

Ah, sorry, actually, it does not work in Py3.2:

>>> import xml.etree.cElementTree as cET
>>> root = cET.Element('root', attrib={'Name':'Root'})
>>> child = cET.SubElement(root, 'child', attrib={'Name':'Child'})
>>> cET.tostring(root)
b'<root attrib="{\'Name\': \'Root\'}"><child attrib="{\'Name\': \'Child\'}" /></root>'

That's even worse than in 2.7 as it doesn't raise an exception.

According to issue 1572710, this is not a bug. The "attrib" argument is supposed to be a positional argument, not a keyword argument. This makes sense, given that arbitrary keyword arguments are accepted for additional XML attributes.

There is still a matter of inconsistency between the two implementations and between 2.7 and 3.x. IMO, the Python-based ElementTree implementation is more graceful at handling the "attrib" argument.

The signature of the factory function Element (and SubElement) in the doc is thus:

    class xml.etree.ElementTree.Element(tag, attrib={}, **extra)


which is fair game for the user to use "attrib" as a keyword argument.

Further, this serialization (in 3.x) does not really make sense, anyway:

>>> cET.tostring(root)
b'<root attrib="{\'Name\': \'Root\'}"><child attrib="{\'Name\': \'Child\'}" /></root>'

Quoting dabrahams in issue 1572710:

On second thought, I see what effbot is trying to say... but it's still a bug. Given the way the interface is declared and the behavior of regular python functions:

  Element(tag, attrib={}, **extra)

indicates that I can pass attrib (or tag, for that matter) as a keyword argument.  Nothing in the documentation gives the C implementation permission to behave differently.

Note that this has been fixed in Py3 already (Py3.3, I guess). The only question is whether the behaviour will be changed in Py2.7.

> Note that this has been fixed in Py3 already (Py3.3, I guess). The only
> question is whether the behaviour will be changed in Py2.7.
>

I don't think this issue is acute enough to warrant fixes in 2.7; however,
a documentation patch would be welcome.

Let's not change this in Py2 anymore.