mirror of
https://github.com/python/cpython.git
synced 2025-12-10 19:10:59 +00:00
whatsnew: XMLPullParser, plus some doc updates.
I was confused by the text saying that read_events "iterated", since it actually returns an iterator (that's what a generator does) that the caller must then iterate. So I tidied up the language. I'm not sure what the sentence "Events provided in a previous call to read_events() will not be yielded again." is trying to convey, so I didn't try to fix that. Also fixed a couple more news items.
This commit is contained in:
parent
aed5b22ead
commit
410d320703
4 changed files with 24 additions and 18 deletions
|
|
@ -105,12 +105,15 @@ Children are nested, and we can access specific child nodes by index::
|
||||||
>>> root[0][1].text
|
>>> root[0][1].text
|
||||||
'2008'
|
'2008'
|
||||||
|
|
||||||
|
|
||||||
|
.. _elementtree-pull-parsing:
|
||||||
|
|
||||||
Pull API for non-blocking parsing
|
Pull API for non-blocking parsing
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
Most parsing functions provided by this module require to read the whole
|
Most parsing functions provided by this module require the whole document
|
||||||
document at once before returning any result. It is possible to use a
|
to be read at once before returning any result. It is possible to use an
|
||||||
:class:`XMLParser` and feed data into it incrementally, but it's a push API that
|
:class:`XMLParser` and feed data into it incrementally, but it is a push API that
|
||||||
calls methods on a callback target, which is too low-level and inconvenient for
|
calls methods on a callback target, which is too low-level and inconvenient for
|
||||||
most needs. Sometimes what the user really wants is to be able to parse XML
|
most needs. Sometimes what the user really wants is to be able to parse XML
|
||||||
incrementally, without blocking operations, while enjoying the convenience of
|
incrementally, without blocking operations, while enjoying the convenience of
|
||||||
|
|
@ -119,7 +122,7 @@ fully constructed :class:`Element` objects.
|
||||||
The most powerful tool for doing this is :class:`XMLPullParser`. It does not
|
The most powerful tool for doing this is :class:`XMLPullParser`. It does not
|
||||||
require a blocking read to obtain the XML data, and is instead fed with data
|
require a blocking read to obtain the XML data, and is instead fed with data
|
||||||
incrementally with :meth:`XMLPullParser.feed` calls. To get the parsed XML
|
incrementally with :meth:`XMLPullParser.feed` calls. To get the parsed XML
|
||||||
elements, call :meth:`XMLPullParser.read_events`. Here's an example::
|
elements, call :meth:`XMLPullParser.read_events`. Here is an example::
|
||||||
|
|
||||||
>>> parser = ET.XMLPullParser(['start', 'end'])
|
>>> parser = ET.XMLPullParser(['start', 'end'])
|
||||||
>>> parser.feed('<mytag>sometext')
|
>>> parser.feed('<mytag>sometext')
|
||||||
|
|
@ -1038,15 +1041,17 @@ XMLPullParser Objects
|
||||||
|
|
||||||
.. method:: read_events()
|
.. method:: read_events()
|
||||||
|
|
||||||
Iterate over the events which have been encountered in the data fed to the
|
Return an iterator over the events which have been encountered in the
|
||||||
parser. This method yields ``(event, elem)`` pairs, where *event* is a
|
data fed to the
|
||||||
|
parser. The iterator yields ``(event, elem)`` pairs, where *event* is a
|
||||||
string representing the type of event (e.g. ``"end"``) and *elem* is the
|
string representing the type of event (e.g. ``"end"``) and *elem* is the
|
||||||
encountered :class:`Element` object.
|
encountered :class:`Element` object.
|
||||||
|
|
||||||
Events provided in a previous call to :meth:`read_events` will not be
|
Events provided in a previous call to :meth:`read_events` will not be
|
||||||
yielded again. As events are consumed from the internal queue only as
|
yielded again. Events are consumed from the internal queue only when
|
||||||
they are retrieved from the iterator, multiple readers calling
|
they are retrieved from the iterator, so multiple readers iterating in
|
||||||
:meth:`read_events` in parallel will have unpredictable results.
|
parallel over iterators obtained from :meth:`read_events` will have
|
||||||
|
unpredictable results.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1088,9 +1088,10 @@ Richard Oudkerk in :issue:`15528`)
|
||||||
xml.etree
|
xml.etree
|
||||||
---------
|
---------
|
||||||
|
|
||||||
Add an event-driven parser for non-blocking applications,
|
A new parser, :class:`~xml.etree.ElementTree.XMLPullParser`, allows a
|
||||||
:class:`~xml.etree.ElementTree.XMLPullParser`.
|
non-blocking applications to parse XML documents. An example can be
|
||||||
(Contributed by Antoine Pitrou in :issue:`17741`.)
|
seen at :ref:`elementtree-pull-parsing`. (Contributed by Antoine
|
||||||
|
Pitrou in :issue:`17741`.)
|
||||||
|
|
||||||
The :mod:`xml.etree.ElementTree` :func:`~xml.etree.ElementTree.tostring` and
|
The :mod:`xml.etree.ElementTree` :func:`~xml.etree.ElementTree.tostring` and
|
||||||
:func:`~xml.etree.ElementTree.tostringlist` functions, and the
|
:func:`~xml.etree.ElementTree.tostringlist` functions, and the
|
||||||
|
|
|
||||||
|
|
@ -1251,7 +1251,7 @@ class XMLPullParser:
|
||||||
self._close_and_return_root()
|
self._close_and_return_root()
|
||||||
|
|
||||||
def read_events(self):
|
def read_events(self):
|
||||||
"""Iterate over currently available (event, elem) pairs.
|
"""Return an iterator over currently available (event, elem) pairs.
|
||||||
|
|
||||||
Events are consumed from the internal event queue as they are
|
Events are consumed from the internal event queue as they are
|
||||||
retrieved from the iterator.
|
retrieved from the iterator.
|
||||||
|
|
|
||||||
10
Misc/NEWS
10
Misc/NEWS
|
|
@ -2193,14 +2193,14 @@ Library
|
||||||
- Issue #17555: Fix ForkAwareThreadLock so that size of after fork
|
- Issue #17555: Fix ForkAwareThreadLock so that size of after fork
|
||||||
registry does not grow exponentially with generation of process.
|
registry does not grow exponentially with generation of process.
|
||||||
|
|
||||||
- Issue #17707: multiprocessing.Queue's get() method does not block for short
|
- Issue #17707: fix regression in multiprocessing.Queue's get() method where
|
||||||
timeouts.
|
it did not block for short timeouts.
|
||||||
|
|
||||||
- Isuse #17720: Fix the Python implementation of pickle.Unpickler to correctly
|
- Issue #17720: Fix the Python implementation of pickle.Unpickler to correctly
|
||||||
process the APPENDS opcode when it is used on non-list objects.
|
process the APPENDS opcode when it is used on non-list objects.
|
||||||
|
|
||||||
- Issue #17012: shutil.which() no longer fallbacks to the PATH environment
|
- Issue #17012: shutil.which() no longer falls back to the PATH environment
|
||||||
variable if empty path argument is specified. Patch by Serhiy Storchaka.
|
variable if an empty path argument is specified. Patch by Serhiy Storchaka.
|
||||||
|
|
||||||
- Issue #17710: Fix pickle raising a SystemError on bogus input.
|
- Issue #17710: Fix pickle raising a SystemError on bogus input.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue