Re: [Python-Dev] cpython: Issue #16148: implemented PEP 424
Am 06.10.2012 14:12, schrieb armin.ronacher: > http://hg.python.org/cpython/rev/a7ec0a1b0f7c > changeset: 79511:a7ec0a1b0f7c > parent: 79507:3c1df1ede882 > user:Armin Ronacher > date:Sat Oct 06 14:03:24 2012 +0200 > summary: > Issue #16148: implemented PEP 424 > > files: > Doc/c-api/object.rst | 7 ++ > Doc/library/operator.rst | 6 + > Include/abstract.h | 5 +- > Lib/test/test_enumerate.py | 9 +- > Lib/test/test_iterlen.py | 62 +-- > Lib/test/test_itertools.py | 5 +- > Lib/test/test_operator.py | 25 > Lib/test/test_set.py | 2 - > Modules/operator.c | 27 > Objects/abstract.c | 80 +++-- > Objects/bytearrayobject.c | 2 +- > Objects/bytesobject.c | 2 +- > Objects/iterobject.c | 11 ++- > Objects/listobject.c | 2 +- > 14 files changed, 162 insertions(+), 83 deletions(-) > > > diff --git a/Doc/c-api/object.rst b/Doc/c-api/object.rst > --- a/Doc/c-api/object.rst > +++ b/Doc/c-api/object.rst > @@ -342,6 +342,13 @@ > returned. This is the equivalent to the Python expression ``len(o)``. > > > +.. c:function:: Py_ssize_t PyObject_LengthHint(PyObject *o, Py_ssize_t > default) > + > + Return an estimated length for the object *o*. First trying to return its > + actual length, then an estimate using ``__length_hint__``, and finally > + returning the default value. On error ``-1`` is returned. This is the > + equivalent to the Python expression ``operator.length_hint(o, default)``. Needs a versionadded. Since __length_hint__ is now official, it needs an entry in Doc/reference/datamodel.rst (which you can link to here.) > .. c:function:: PyObject* PyObject_GetItem(PyObject *o, PyObject *key) > > Return element of *o* corresponding to the object *key* or *NULL* on > failure. > diff --git a/Doc/library/operator.rst b/Doc/library/operator.rst > --- a/Doc/library/operator.rst > +++ b/Doc/library/operator.rst > @@ -235,6 +235,12 @@ > > .. XXX: find a better, readable, example > > +.. function:: length_hint(obj, default=0) > + > + Return an estimated length for the object *o*. First trying to return its > + actual length, then an estimate using ``__length_hint__``, and finally > + returning the default value. This one also needs versionadded and a link to __length_hint__. > The :mod:`operator` module also defines tools for generalized attribute and > item > lookups. These are useful for making fast field extractors as arguments for > :func:`map`, :func:`sorted`, :meth:`itertools.groupby`, or other functions > that > diff --git a/Include/abstract.h b/Include/abstract.h > --- a/Include/abstract.h > +++ b/Include/abstract.h > @@ -403,9 +403,8 @@ > PyAPI_FUNC(Py_ssize_t) PyObject_Length(PyObject *o); > #define PyObject_Length PyObject_Size > > -#ifndef Py_LIMITED_API > - PyAPI_FUNC(Py_ssize_t) _PyObject_LengthHint(PyObject *o, Py_ssize_t); > -#endif > +PyAPI_FUNC(int) _PyObject_HasLen(PyObject *o); > +PyAPI_FUNC(Py_ssize_t) PyObject_LengthHint(PyObject *o, Py_ssize_t); Not sure if new functions should be included in the limited API. I seem to recall some discussion about giving Py_LIMITED_API a numeric value for the required API version? PEP 384 is silent about it. > /* > Guess the size of object o using len(o) or o.__length_hint__(). > diff --git a/Lib/test/test_enumerate.py b/Lib/test/test_enumerate.py > --- a/Lib/test/test_enumerate.py > +++ b/Lib/test/test_enumerate.py > @@ -1,4 +1,5 @@ > import unittest > +import operator > import sys > import pickle > > @@ -168,15 +169,13 @@ > x = range(1) > self.assertEqual(type(reversed(x)), type(iter(x))) > > [email protected]_only > def test_len(self): > # This is an implementation detail, not an interface requirement If it's not cpython_only anymore, this comment should also vanish? > -from test.test_iterlen import len > for s in ('hello', tuple('hello'), list('hello'), range(5)): > -self.assertEqual(len(reversed(s)), len(s)) > +self.assertEqual(operator.length_hint(reversed(s)), len(s)) > r = reversed(s) > list(r) > -self.assertEqual(len(r), 0) > +self.assertEqual(operator.length_hint(r), 0) > class SeqWithWeirdLen: > called = False > def __len__(self): > @@ -187,7 +186,7 @@ > def __getitem__(self, index): > return index > r = reversed(SeqWithWeirdLen()) > -self.assertRaises(ZeroDivisionError, len, r) > +self.assertRaises(ZeroDivisionError, operator.length_hint, r) > > > def test_gc(self): > diff --git a/Lib/test/test_iterlen.py b/Lib/test/test_iterlen.py > --- a/Lib/test/test_iterlen.py > +++ b/Lib/test/test_iterlen.py > @@ -45,31 +45,21 @@ > from test import support > from itertools im
Re: [Python-Dev] cpython: Issue #16148: implemented PEP 424
On Sat, 6 Oct 2012 14:12:36 +0200 (CEST) armin.ronacher wrote: > http://hg.python.org/cpython/rev/a7ec0a1b0f7c > changeset: 79511:a7ec0a1b0f7c > parent: 79507:3c1df1ede882 > user:Armin Ronacher > date:Sat Oct 06 14:03:24 2012 +0200 > summary: > Issue #16148: implemented PEP 424 > [...] > > +.. c:function:: Py_ssize_t PyObject_LengthHint(PyObject *o, Py_ssize_t > default) > + > + Return an estimated length for the object *o*. First trying to return its > + actual length, then an estimate using ``__length_hint__``, and finally > + returning the default value. On error ``-1`` is returned. This is the > + equivalent to the Python expression ``operator.length_hint(o, default)``. > + You need a "versionadded" marker. > +.. function:: length_hint(obj, default=0) > + > + Return an estimated length for the object *o*. First trying to return its > + actual length, then an estimate using ``__length_hint__``, and finally > + returning the default value. > + Here as well. > -#ifndef Py_LIMITED_API > - PyAPI_FUNC(Py_ssize_t) _PyObject_LengthHint(PyObject *o, Py_ssize_t); > -#endif > +PyAPI_FUNC(int) _PyObject_HasLen(PyObject *o); > +PyAPI_FUNC(Py_ssize_t) PyObject_LengthHint(PyObject *o, Py_ssize_t); If _PyObject_HasLen is private, it shouldn't be in the Py_LIMITED_API. > diff --git a/Lib/test/test_enumerate.py b/Lib/test/test_enumerate.py > --- a/Lib/test/test_enumerate.py > +++ b/Lib/test/test_enumerate.py > @@ -1,4 +1,5 @@ > import unittest > +import operator > import sys > import pickle > > @@ -168,15 +169,13 @@ > x = range(1) > self.assertEqual(type(reversed(x)), type(iter(x))) > > [email protected]_only > def test_len(self): > # This is an implementation detail, not an interface requirement > -from test.test_iterlen import len > for s in ('hello', tuple('hello'), list('hello'), range(5)): > -self.assertEqual(len(reversed(s)), len(s)) > +self.assertEqual(operator.length_hint(reversed(s)), len(s)) You should still test len() as well, no? > +else { > +return res; > +} > +PyObject *hint = _PyObject_LookupSpecial(o, &PyId___length_hint__); Putting variable declarations in the middle of code blocks is not C89-compliant. You probably broke a couple of buildbots :-) > +if (_PyObject_HasLen(it->it_seq)) { > +seqsize = PySequence_Size(it->it_seq); > +if (seqsize == -1) > +return NULL; > +} > +else { > +return Py_NotImplemented; > +} Lacks a Py_INCREF? Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad python 2.5 build on OSX 10.8 mountain lion
On Fri, Oct 5, 2012 at 4:45 PM, Ned Deily wrote: > In article , > Ned Deily wrote: >> In article <[email protected]>, >> Stefan Krah wrote: >> > Ned Deily wrote: >> > > > Forgot the link... >> > > > http://code.google.com/p/googleappengine/issues/detail?id=7885 >> > > > On Monday, October 1, 2012, Guido van Rossum wrote: >> > > > > As discussed here, the python 2.5 binary distributed by Apple on >> > > > > mountain >> > > > > lion is broken. Could someone file an official complaint? >> > > I've filed a bug against 10.8 python2.5. The 10.8 versions of Apple's >> > > pythons are compile with clang and we did see some sign extension issues >> > > with ctypes. The 10.7 version of Apple's python2.5 is compiled with >> > > llvm-gcc and handles 2**31 correctly. >> > Yes, this looks like http://bugs.python.org/issue11149 . >> Ah, right, thanks. I've updated the Apple issue accordingly. > > Update: the bug I filed has been closed as a duplicate of #11932488 > which apparently at the moment is still open. No other information is > available. Thanks Ned! Is there any way that I could see that bug myself and attach myself to updates? Otherwise, can you keep us here appraised of developments (even if Apple decides not to fix it)? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad python 2.5 build on OSX 10.8 mountain lion
In article , Guido van Rossum wrote: > On Fri, Oct 5, 2012 at 4:45 PM, Ned Deily wrote: > > In article , > > Update: the bug I filed has been closed as a duplicate of #11932488 > > which apparently at the moment is still open. No other information is > > available. > > Thanks Ned! Is there any way that I could see that bug myself and > attach myself to updates? Otherwise, can you keep us here appraised of > developments (even if Apple decides not to fix it)? I don't think there's any way to see any bug other than ones you have submitted yourself. All I can see is that the bug I submitted is closed as a duplicate and now has a Related Problem section that only gives the other incident number and its status (Open). I can't view anything else about that other incident. I don't know if I'll get an email update if its status changes. I'll keep an eye on mine and perhaps ask for a status update if nothing changes in a few weeks. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad python 2.5 build on OSX 10.8 mountain lion
Thanks, Ned. Do you think it would be worth it to use our contacts at Apple to raise the priority of this embarrassment? On Saturday, October 6, 2012, Ned Deily wrote: > In article > > >, > Guido van Rossum > wrote: > > On Fri, Oct 5, 2012 at 4:45 PM, Ned Deily > > wrote: > > > In article >, > > > Update: the bug I filed has been closed as a duplicate of #11932488 > > > which apparently at the moment is still open. No other information is > > > available. > > > > Thanks Ned! Is there any way that I could see that bug myself and > > attach myself to updates? Otherwise, can you keep us here appraised of > > developments (even if Apple decides not to fix it)? > > I don't think there's any way to see any bug other than ones you have > submitted yourself. All I can see is that the bug I submitted is closed > as a duplicate and now has a Related Problem section that only gives the > other incident number and its status (Open). I can't view anything else > about that other incident. I don't know if I'll get an email update if > its status changes. I'll keep an eye on mine and perhaps ask for a > status update if nothing changes in a few weeks. > > -- > Ned Deily, > [email protected] > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bad python 2.5 build on OSX 10.8 mountain lion
On Oct 6, 2012, at 20:47 , Guido van Rossum wrote: > On Saturday, October 6, 2012, Ned Deily wrote: > In article >> , >> Guido van Rossum wrote: >> > On Fri, Oct 5, 2012 at 4:45 PM, Ned Deily wrote: >> > > In article , >> > > Update: the bug I filed has been closed as a duplicate of #11932488 >> > > which apparently at the moment is still open. No other information is >> > > available. >> > >> > Thanks Ned! Is there any way that I could see that bug myself and >> > attach myself to updates? Otherwise, can you keep us here appraised of >> > developments (even if Apple decides not to fix it)? >> >> I don't think there's any way to see any bug other than ones you have >> submitted yourself. All I can see is that the bug I submitted is closed >> as a duplicate and now has a Related Problem section that only gives the >> other incident number and its status (Open). I can't view anything else >> about that other incident. I don't know if I'll get an email update if >> its status changes. I'll keep an eye on mine and perhaps ask for a >> status update if nothing changes in a few weeks. > Thanks, Ned. Do you think it would be worth it to use our contacts at Apple > to raise the priority of this embarrassment? It might help if anyone wants to try. On the other hand, Python 2.5 is probably not the highest priority for Apple since they also ship Python 2.6 and 2.7 with 10.8, neither of which have this problem. I'll see if I can get an official status update on mine (#12411585). -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
