<p dir="ltr"><br>
On 5 Jan 2014 12:54, "r.david.murray" <<a href="mailto:python-checkins@python.org">python-checkins@python.org</a>> wrote:<br>
><br>
> <a href="http://hg.python.org/cpython/rev/069f88f4935f">http://hg.python.org/cpython/rev/069f88f4935f</a><br>
> changeset: 88308:069f88f4935f<br>
> user: R David Murray <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>><br>
> date: Sat Jan 04 23:52:50 2014 -0500<br>
> summary:<br>
> whatsnew: XMLPullParser, plus some doc updates.<br>
><br>
> I was confused by the text saying that read_events "iterated", since it<br>
> actually returns an iterator (that's what a generator does) that the<br>
> caller must then iterate. So I tidied up the language. I'm not sure<br>
> what the sentence "Events provided in a previous call to read_events()<br>
> will not be yielded again." is trying to convey, so I didn't try to fix that.</p>
<p dir="ltr">It's a mutating API - once the events have been retrieved, that's it, they're gone from the internal state. Suggestions for wording improvements welcome :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Also fixed a couple more news items.<br>
><br>
> files:<br>
> Doc/library/xml.etree.elementtree.rst | 23 +++++++++-----<br>
> Doc/whatsnew/3.4.rst | 7 ++-<br>
> Lib/xml/etree/ElementTree.py | 2 +-<br>
> Misc/NEWS | 12 +++---<br>
> 4 files changed, 25 insertions(+), 19 deletions(-)<br>
><br>
><br>
> diff --git a/Doc/library/xml.etree.elementtree.rst b/Doc/library/xml.etree.elementtree.rst<br>
> --- a/Doc/library/xml.etree.elementtree.rst<br>
> +++ b/Doc/library/xml.etree.elementtree.rst<br>
> @@ -105,12 +105,15 @@<br>
> >>> root[0][1].text<br>
> '2008'<br>
><br>
> +<br>
> +.. _elementtree-pull-parsing:<br>
> +<br>
> Pull API for non-blocking parsing<br>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
><br>
> -Most parsing functions provided by this module require to read the whole<br>
> -document at once before returning any result. It is possible to use a<br>
> -:class:`XMLParser` and feed data into it incrementally, but it's a push API that<br>
> +Most parsing functions provided by this module require the whole document<br>
> +to be read at once before returning any result. It is possible to use an<br>
> +:class:`XMLParser` and feed data into it incrementally, but it is a push API that<br>
> calls methods on a callback target, which is too low-level and inconvenient for<br>
> most needs. Sometimes what the user really wants is to be able to parse XML<br>
> incrementally, without blocking operations, while enjoying the convenience of<br>
> @@ -119,7 +122,7 @@<br>
> The most powerful tool for doing this is :class:`XMLPullParser`. It does not<br>
> require a blocking read to obtain the XML data, and is instead fed with data<br>
> incrementally with :meth:`XMLPullParser.feed` calls. To get the parsed XML<br>
> -elements, call :meth:`XMLPullParser.read_events`. Here's an example::<br>
> +elements, call :meth:`XMLPullParser.read_events`. Here is an example::<br>
><br>
> >>> parser = ET.XMLPullParser(['start', 'end'])<br>
> >>> parser.feed('<mytag>sometext')<br>
> @@ -1038,15 +1041,17 @@<br>
><br>
> .. method:: read_events()<br>
><br>
> - Iterate over the events which have been encountered in the data fed to the<br>
> - parser. This method yields ``(event, elem)`` pairs, where *event* is a<br>
> + Return an iterator over the events which have been encountered in the<br>
> + data fed to the<br>
> + parser. The iterator yields ``(event, elem)`` pairs, where *event* is a<br>
> string representing the type of event (e.g. ``"end"``) and *elem* is the<br>
> encountered :class:`Element` object.<br>
><br>
> Events provided in a previous call to :meth:`read_events` will not be<br>
> - yielded again. As events are consumed from the internal queue only as<br>
> - they are retrieved from the iterator, multiple readers calling<br>
> - :meth:`read_events` in parallel will have unpredictable results.<br>
> + yielded again. Events are consumed from the internal queue only when<br>
> + they are retrieved from the iterator, so multiple readers iterating in<br>
> + parallel over iterators obtained from :meth:`read_events` will have<br>
> + unpredictable results.<br>
><br>
> .. note::<br>
><br>
> diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst<br>
> --- a/Doc/whatsnew/3.4.rst<br>
> +++ b/Doc/whatsnew/3.4.rst<br>
> @@ -1088,9 +1088,10 @@<br>
> xml.etree<br>
> ---------<br>
><br>
> -Add an event-driven parser for non-blocking applications,<br>
> -:class:`~xml.etree.ElementTree.XMLPullParser`.<br>
> -(Contributed by Antoine Pitrou in :issue:`17741`.)<br>
> +A new parser, :class:`~xml.etree.ElementTree.XMLPullParser`, allows a<br>
> +non-blocking applications to parse XML documents. An example can be<br>
> +seen at :ref:`elementtree-pull-parsing`. (Contributed by Antoine<br>
> +Pitrou in :issue:`17741`.)<br>
><br>
> The :mod:`xml.etree.ElementTree` :func:`~xml.etree.ElementTree.tostring` and<br>
> :func:`~xml.etree.ElementTree.tostringlist` functions, and the<br>
> diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py<br>
> --- a/Lib/xml/etree/ElementTree.py<br>
> +++ b/Lib/xml/etree/ElementTree.py<br>
> @@ -1251,7 +1251,7 @@<br>
> self._close_and_return_root()<br>
><br>
> def read_events(self):<br>
> - """Iterate over currently available (event, elem) pairs.<br>
> + """Return an iterator over currently available (event, elem) pairs.<br>
><br>
> Events are consumed from the internal event queue as they are<br>
> retrieved from the iterator.<br>
> diff --git a/Misc/NEWS b/Misc/NEWS<br>
> --- a/Misc/NEWS<br>
> +++ b/Misc/NEWS<br>
> @@ -2193,14 +2193,14 @@<br>
> - Issue #17555: Fix ForkAwareThreadLock so that size of after fork<br>
> registry does not grow exponentially with generation of process.<br>
><br>
> -- Issue #17707: multiprocessing.Queue's get() method does not block for short<br>
> - timeouts.<br>
> -<br>
> -- Isuse #17720: Fix the Python implementation of pickle.Unpickler to correctly<br>
> +- Issue #17707: fix regression in multiprocessing.Queue's get() method where<br>
> + it did not block for short timeouts.<br>
> +<br>
> +- Issue #17720: Fix the Python implementation of pickle.Unpickler to correctly<br>
> process the APPENDS opcode when it is used on non-list objects.<br>
><br>
> -- Issue #17012: shutil.which() no longer fallbacks to the PATH environment<br>
> - variable if empty path argument is specified. Patch by Serhiy Storchaka.<br>
> +- Issue #17012: shutil.which() no longer falls back to the PATH environment<br>
> + variable if an empty path argument is specified. Patch by Serhiy Storchaka.<br>
><br>
> - Issue #17710: Fix pickle raising a SystemError on bogus input.<br>
><br>
><br>
> --<br>
> Repository URL: <a href="http://hg.python.org/cpython">http://hg.python.org/cpython</a><br>
><br>
> _______________________________________________<br>
> Python-checkins mailing list<br>
> <a href="mailto:Python-checkins@python.org">Python-checkins@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-checkins">https://mail.python.org/mailman/listinfo/python-checkins</a><br>
><br>
</p>