homepage

In xml.etree, ElementTree and cElementTree implement different interfaces for the iterparse function/class.
In ElementTree, the argument "events" must be a tuple of strings:
from xml.etree import ElementTree as ET
for result in ET.iterparse('example.xml', events=('start', 'end')):
 print(result)
That works, given a valid XML file 'example.xml'. If the event names are given as bytes instead of strings (b'start', b'end'), there's no crash, but no events are recognized.
In cElementTree, it's the opposite: the events argument must be a tuple of bytes:
from xml.etree import cElementTree as cET
for result in cET.iterparse('example.xml', events=(b'start', b'end')):
 print(result)
Giving a tuple of strings instead of bytes results in:
>>> for result in cET.iterparse('example.xml', events=('start', 'end')):
... print(result)
TypeError: invalid event tuple
This makes it difficult to use ElementTree as a backup for cElementTree, or at least very awkward.

It seems that this has been fixed in the py3k branch (r78942). Now both bytes and unicode are accepted. Can someone check?

This bug seems to be still present in Python 3.1.2. (Unless I'm doing something wrong.) Was r78942 included in the 3.1.2 release?

No, apparently, r78942 was not included in 3.1.2.

This wasn't fixed in Python 3.1.3 either.
Is the trunk commit Amaury identified from py3k branch (r78942) suitable to back port to Python 3.1.x?

r78942 is quite large unfortunately.
But just patching _elementree.c::xmlparser_setevents() should be possible.
This would at least fix the "invalid event tuple" error.

At this point, 3.1 won't be fixed with such changes any longer.
Is this fixed in 3.2/3.3?

It's more-or-less fixed in Python 3.2:
- With cElementTree, both bytes and strings are accepted for events; 
- With ElementTree, only strings are accepted, and bytes raise a ValueError (unknown event).
A small inconsistency remains, but it's fine to just use strings in all cases.

Eric,
Thanks for checking. I agree that this behavior is acceptable, but a documentation fix would be appropriate. The documentation of iterparse should mention the events it accepts, also saying that those are strings. 
The events are listed at http://effbot.org/zone/element-iterparse.htm
Would you like to try your hand at submitting a patch for Python 3.2? I will review and apply it to 3.2 and 3.3

Changing the target version(s) and adding some documentation experts to the nosy list

Well, this is not the best month for me to try digging into a new codebase... I would not mind if someone else did the patch for this.

New changeset 84e4d76bd146 by Eli Bendersky in branch '3.2':
Issue #9257: clarify the events iterparse accepts
http://hg.python.org/cpython/rev/84e4d76bd146
New changeset 00c7142ee54a by Eli Bendersky in branch 'default':
Issue #9257: clarify the events iterparse accepts
http://hg.python.org/cpython/rev/00c7142ee54a