Mailman 3 January 2014 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython: whatsnew: XMLPullParser, plus some doc updates.
by Nick Coghlan Jan. 6, 2014

Jan. 6, 2014

On 5 Jan 2014 12:54, "r.david.murray" <python-checkins(a)python.org> wrote: > > http://hg.python.org/cpython/rev/069f88f4935f > changeset: 88308:069f88f4935f > user: R David Murray <rdmurray(a)bitdance.com> > date: Sat Jan 04 23:52:50 2014 -0500 > summary: > 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 … [View More]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. 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 :) Cheers, Nick. > > Also fixed a couple more news items. > > files: > Doc/library/xml.etree.elementtree.rst | 23 +++++++++----- > Doc/whatsnew/3.4.rst | 7 ++- > Lib/xml/etree/ElementTree.py | 2 +- > Misc/NEWS | 12 +++--- > 4 files changed, 25 insertions(+), 19 deletions(-) > > > diff --git a/Doc/library/xml.etree.elementtree.rst b/Doc/library/xml.etree.elementtree.rst > --- a/Doc/library/xml.etree.elementtree.rst > +++ b/Doc/library/xml.etree.elementtree.rst > @@ -105,12 +105,15 @@ > >>> root[0][1].text > '2008' > > + > +.. _elementtree-pull-parsing: > + > Pull API for non-blocking parsing > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -Most parsing functions provided by this module require to read the whole > -document at once before returning any result. It is possible to use a > -:class:`XMLParser` and feed data into it incrementally, but it's a push API that > +Most parsing functions provided by this module require the whole document > +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 is a push API that > 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 > incrementally, without blocking operations, while enjoying the convenience of > @@ -119,7 +122,7 @@ > 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 > 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.feed('<mytag>sometext') > @@ -1038,15 +1041,17 @@ > > .. method:: read_events() > > - Iterate over the events which have been encountered in the data fed to the > - parser. This method yields ``(event, elem)`` pairs, where *event* is a > + Return an iterator over the events which have been encountered in the > + 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 > encountered :class:`Element` object. > > 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 > - they are retrieved from the iterator, multiple readers calling > - :meth:`read_events` in parallel will have unpredictable results. > + yielded again. Events are consumed from the internal queue only when > + they are retrieved from the iterator, so multiple readers iterating in > + parallel over iterators obtained from :meth:`read_events` will have > + unpredictable results. > > .. note:: > > diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst > --- a/Doc/whatsnew/3.4.rst > +++ b/Doc/whatsnew/3.4.rst > @@ -1088,9 +1088,10 @@ > xml.etree > --------- > > -Add an event-driven parser for non-blocking applications, > -:class:`~xml.etree.ElementTree.XMLPullParser`. > -(Contributed by Antoine Pitrou in :issue:`17741`.) > +A new parser, :class:`~xml.etree.ElementTree.XMLPullParser`, allows a > +non-blocking applications to parse XML documents. An example can be > +seen at :ref:`elementtree-pull-parsing`. (Contributed by Antoine > +Pitrou in :issue:`17741`.) > > The :mod:`xml.etree.ElementTree` :func:`~xml.etree.ElementTree.tostring` and > :func:`~xml.etree.ElementTree.tostringlist` functions, and the > diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py > --- a/Lib/xml/etree/ElementTree.py > +++ b/Lib/xml/etree/ElementTree.py > @@ -1251,7 +1251,7 @@ > self._close_and_return_root() > > 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 > retrieved from the iterator. > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -2193,14 +2193,14 @@ > - Issue #17555: Fix ForkAwareThreadLock so that size of after fork > registry does not grow exponentially with generation of process. > > -- Issue #17707: multiprocessing.Queue's get() method does not block for short > - timeouts. > - > -- Isuse #17720: Fix the Python implementation of pickle.Unpickler to correctly > +- Issue #17707: fix regression in multiprocessing.Queue's get() method where > + it did not block for short timeouts. > + > +- Issue #17720: Fix the Python implementation of pickle.Unpickler to correctly > process the APPENDS opcode when it is used on non-list objects. > > -- Issue #17012: shutil.which() no longer fallbacks to the PATH environment > - variable if empty path argument is specified. Patch by Serhiy Storchaka. > +- Issue #17012: shutil.which() no longer falls back to the PATH environment > + variable if an empty path argument is specified. Patch by Serhiy Storchaka. > > - Issue #17710: Fix pickle raising a SystemError on bogus input. > > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > https://mail.python.org/mailman/listinfo/python-checkins > [View Less]

2 1

Python 2.7 root buildbot showing errors
by Chris Angelico Jan. 6, 2014

Jan. 6, 2014

The first build my new root buildbot did showed errors in the 2.7 test suite, but I thought little of it as quite a few other 2.7 buildbots are showing red, too. But it seems they're showing different errors, so there might be something wrong with the setup. http://buildbot.python.org/all/builders/AMD64%20Debian%20root%202.7/builds/… First off, it's complaining about being unable to build _curses (lacking curses.h). Is that a mandatory prereq that I should install, or should Python be … [View More]

3 5

Subclasses vs. special methods
by Serhiy Storchaka Jan. 6, 2014

Jan. 6, 2014

Should implicit converting an instance of int, float, complex, str, bytes, etc subclasses to call appropriate special method __int__ (or __index__), __float__, __complex__, __str__, __bytes__, etc? Currently explicit converting calls these methods, but implicit converting doesn't. >>> class I(int): ... def __int__(self): return 42 ... def __index__(self): return 43 ... >>> class F(float): ... def __float__(self): return 42.0 ... >>> class S(str): ... … [View More]

2 1

2.x vs 3.x survey results
by Dan Stromberg Jan. 6, 2014

Jan. 6, 2014

Is there a better place to put this than: http://stromberg.dnsalias.org/~strombrg/python-2.x-vs-3.x-survey/ Thanks.

14 20

[RELEASE] libmpdec-2.4.0 (suitable for compiling _decimal)
by Stefan Krah Jan. 5, 2014

Jan. 5, 2014

Hi, I've released libmpdec-2.4.0, which can be used to compile _decimal with the "--with-system-libmpdec" configure option: http://www.bytereef.org/mpdecimal/download.html libmpdec-2.4.0 is exactly the same as the one in the CPython source tree. The API is stable and the libmpdec-2.x.y series will stay binary compatible [1]. Stefan Krah [1] Starting from 2.4.0: 2.4.0 is not binary compatible with 2.3.

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #19976: Argument Clinic METH_NOARGS functions now always
by Stefan Krah Jan. 4, 2014

Jan. 4, 2014

Probably Rietveld did not send mail, so I mention my review comments again: larry.hastings <python-checkins(a)python.org> wrote: > +#ifdef __GNUC__ > +#define Py_UNUSED(name) _unused_ ## name __attribute__((unused)) > +#else > +#define Py_UNUSED(name) _unused_ ## name > +#endif > + The Intel compiler defines __GNUC__ but chokes on the __attribute__(). This works: #if defined(__GNUC__) && !defined(__INTEL_COMPILER) > +_pickle_Pickler_clear_memo(PyObject *… [View More]

2 2

Bug? http.client assumes iso-8859-1 encoding of HTTP headers
by Hugo G. Fierro Jan. 4, 2014

Jan. 4, 2014

Hi Python devs, I am trying to download an HTML document. I get an HTTP 301 (Moved Permanently) with a UTF-8 encoded Location header and http.client decodes it as iso-8859-1. When there's a non-ASCII character in the redirect URL then I can't download the document. In client.py def parse_headers() I see the call to decode('iso-8859-1'). My personal hack is to use whatever charset is defined in the Content-Type HTTP header (utf8) or fall back into iso-8859-1. At this point I am not sure … [View More]

4 3

Re: [Python-Dev] cpython: threading.RLock._acquire_restore() now raises a TypeError instead of a
by Serhiy Storchaka Jan. 4, 2014

Jan. 4, 2014

02.01.14 13:54, victor.stinner написав(ла): > http://hg.python.org/cpython/rev/9a61be172c23 > changeset: 88249:9a61be172c23 > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Thu Jan 02 12:47:24 2014 +0100 > summary: > threading.RLock._acquire_restore() now raises a TypeError instead of a > SystemError when it is not called with 2 arguments > - if (!PyArg_ParseTuple(arg, "kl:_acquire_restore", &count, &owner)) > + if (!… [View More]

3 3

Summary of Python tracker Issues
by Python tracker Jan. 3, 2014

Jan. 3, 2014

ACTIVITY SUMMARY (2013-12-27 - 2014-01-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4348 (+16) closed 27538 (+18) total 31886 (+34) Open issues with patches: 1977 Issues opened (27) ================== #18310: itertools.tee() can't accept keyword arguments http://bugs.python.org/issue18310 reopened by py.user #20081: sys.getwindowsversion … [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython: add unicode_char() in unicodeobject.c to factorize code
by Zachary Ware Jan. 3, 2014

Jan. 3, 2014

On Fri, Jan 3, 2014 at 6:01 AM, victor.stinner <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/d453c95def31 > changeset: 88271:d453c95def31 > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Fri Jan 03 12:53:47 2014 +0100 > summary: > add unicode_char() in unicodeobject.c to factorize code > > files: > Objects/unicodeobject.c | 86 ++++++++++------------------ > 1 files changed, 31 insertions(+), … [View More]55 deletions(-) > > > diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c > --- a/Objects/unicodeobject.c > +++ b/Objects/unicodeobject.c <snip> > @@ -2887,17 +2883,7 @@ > return NULL; > } > > - if ((Py_UCS4)ordinal < 256) > - return get_latin1_char((unsigned char)ordinal); > - > - v = PyUnicode_New(1, ordinal); > - if (v == NULL) > - return NULL; > - kind = PyUnicode_KIND(v); > - data = PyUnicode_DATA(v); > - PyUnicode_WRITE(kind, data, 0, ordinal); > - assert(_PyUnicode_CheckConsistency(v, 1)); > - return v; > + return unicode_char((Py_UCS4)ordinal); > } > > PyObject * > @@ -11354,17 +11340,7 @@ > kind = PyUnicode_KIND(self); > data = PyUnicode_DATA(self); > ch = PyUnicode_READ(kind, data, index); > - if (ch < 256) > - return get_latin1_char(ch); > - > - res = PyUnicode_New(1, ch); > - if (res == NULL) > - return NULL; > - kind = PyUnicode_KIND(res); > - data = PyUnicode_DATA(res); > - PyUnicode_WRITE(kind, data, 0, ch); > - assert(_PyUnicode_CheckConsistency(res, 1)); > - return res; > + return unicode_char(ch); > } > > /* Believe it or not, this produces the same value for ASCII strings The above-quoted parts of this changeset caused several compiler warnings due to unused variables. On 32-bit Windows: ..\Objects\unicodeobject.c(2881): warning C4101: 'kind' : unreferenced local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj] ..\Objects\unicodeobject.c(2879): warning C4101: 'v' : unreferenced local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj] ..\Objects\unicodeobject.c(2880): warning C4101: 'data' : unreferenced local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj] ..\Objects\unicodeobject.c(11333): warning C4101: 'res' : unreferenced local variable [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj] I believe this should fix it, but I'll leave it up to you to confirm that, Victor :) diff -r 8a3718f31188 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jan 03 15:53:20 2014 +0100 +++ b/Objects/unicodeobject.c Fri Jan 03 10:20:12 2014 -0600 @@ -2876,10 +2876,6 @@ PyObject * PyUnicode_FromOrdinal(int ordinal) { - PyObject *v; - void *data; - int kind; - if (ordinal < 0 || ordinal > MAX_UNICODE) { PyErr_SetString(PyExc_ValueError, "chr() arg not in range(0x110000)"); @@ -11330,7 +11326,6 @@ void *data; enum PyUnicode_Kind kind; Py_UCS4 ch; - PyObject *res; if (!PyUnicode_Check(self) || PyUnicode_READY(self) == -1) { PyErr_BadArgument(); -- Zach [View Less]

2 1