bpo-36673: Implement comment/PI parsing support for the TreeBuilder in ElementTree. #12883
Conversation
scoder
force-pushed
the
bpo-36673_etree_comments
branch
from
ae11dac to
864b1e5
Compare
scoder
force-pushed
the
bpo-36673_etree_comments
branch
from
864b1e5 to
ab7341d
Compare
|
I thought about this some more and also took another look at the respective interface in lxml. I originally thought it would be nice to have something simple and fast for the event iteration (i.e. the plain comment text for comments and a |
| @@ -1172,6 +1202,10 @@ XMLPullParser Objects | |||
| parser. The iterator yields ``(event, elem)`` pairs, where *event* is a | |||
There was a problem hiding this comment.
Maybe rename elem to data or payload or whatever (since it is not always an element) and document its meaning uniformly for all events (maybe using an unordered list)?
There was a problem hiding this comment.
Agreed that it's not ideal, but with the change that I'm currently working up, it's going to be an Element-like object (Element, Comment, PI) most of the time. For many use cases, it's really only an only Element, especially in the default end-only-events case. Also, elem, i.e. element, is a fairly generic term, even though its meaning is tighter in the context of ElementTree.
I've also thought of using a more structured way of presenting it, and I think I'll do that.
…r in "_elementtree" to make it use the same factories as the ElementTree module, and to make it explicit when the comments/PIs are inserted into the tree and when they are not (which is the default).
scoder
force-pushed
the
bpo-36673_etree_comments
branch
from
c17eca6 to
2d2df11
Compare
|
Turns out, it's not that easy to get the Comment/PI factories into I solved this by adding a "private" |
|
@scoder: Please replace |
| @@ -2925,7 +3147,7 @@ expat_set_error(enum XML_Error error_code, Py_ssize_t line, Py_ssize_t column, | |||
| if (errmsg == NULL) | |||
| return; | |||
|
|
|||
| error = PyObject_CallFunctionObjArgs(st->parseerror_obj, errmsg, NULL); | |||
| error = _PyObject_FastCall(st->parseerror_obj, &errmsg, 1); | |||
There was a problem hiding this comment.
FWIW, I'm not sure if these _PyObject_FastCall() additions in _elementtree.c should have been made as part of this PR -- they are quite unrelated to the BPO issue.
There was a problem hiding this comment.
Granted. I made them for the new code I wrote, so I consider it a bit of a consistency cleanup to use them in all similar places. Note that I also tried to apply the general implementation pattern to all the handler functions that either dispatches to the treebuilder or to a Python function. Given how repetitive this code becomes in C, I think avoiding surprises in the implementation is important to simplify the future maintenance.
https://bugs.python.org/issue36673