Mailman 3 February 2016 - Python-checkins

NEUTRAL Benchmark Results for Python 2.7 2016-02-02
by lp_benchmark_robot＠intel.com 02 Feb '16

02 Feb '16

Results for project Python 2.7, build date 2016-02-02 04:00:11 +0000 commit: 6f7b2b7a029a previous commit: 296fb7c10a7d revision date: 2016-02-01 21:58:11 +0000 environment: Haswell-EP cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem: 128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release v2.7.10, with hash 15c95b7d81dc from 2015-05-23 16:02:14+00:00 ---------------------------------------------------------------------------------- benchmark relative change since change since current rev run std_dev* last run baseline with PGO ---------------------------------------------------------------------------------- :-) django_v2 0.18% 0.78% 2.40% 4.82% :-) pybench 0.17% 0.14% 6.20% 4.74% :-( regex_v8 0.63% -0.04% -2.41% 11.11% :-) nbody 0.18% 0.10% 8.11% 1.16% :-) json_dump_v2 0.27% -0.01% 4.66% 10.40% :-( normal_startup 2.01% 0.83% -4.97% 2.11% :-| ssbench 0.21% -0.18% 0.73% 1.65% ---------------------------------------------------------------------------------- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-python-… Note: Benchmark results for ssbench are measured in requests/second while all other are measured in seconds. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the Python project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration.

1 0

GOOD Benchmark Results for Python Default 2016-02-02
by lp_benchmark_robot＠intel.com 02 Feb '16

02 Feb '16

Results for project Python default, build date 2016-02-02 03:08:41 +0000 commit: 3b211ee66b82 previous commit: c7f1acdd8be1 revision date: 2016-02-01 11:47:15 +0000 environment: Haswell-EP cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem: 128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release v3.4.3, with hash b4cbecbc0781 from 2015-02-25 12:15:33+00:00 ---------------------------------------------------------------------------------- benchmark relative change since change since current rev run std_dev* last run baseline with PGO ---------------------------------------------------------------------------------- :-) django_v2 0.24% 1.13% 9.84% 15.66% :-| pybench 0.09% -0.10% -1.17% 4.45% :-( regex_v8 2.79% -0.04% -3.28% 4.11% :-| nbody 0.10% -0.06% 0.44% 4.04% :-| json_dump_v2 0.26% 0.21% -1.56% 9.13% :-| normal_startup 0.84% -0.17% 0.25% 5.13% ---------------------------------------------------------------------------------- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/good-benchmark-results-for-python-def… Note: Benchmark results are measured in seconds. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the Python project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration.

1 0

Daily reference leaks (0731f097157b): sum=4
by solipsis＠pitrou.net 02 Feb '16

02 Feb '16

results for 0731f097157b on branch "default" -------------------------------------------- test_functools leaked [0, 2, 2] memory blocks, sum=4 Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogHbfF3e', '--timeout', '7200']

1 0

cpython (2.7): Issue #26244: Clarify default zlib compression level in documentation
by martin.panter 02 Feb '16

02 Feb '16

https://hg.python.org/cpython/rev/650cf38fba28 changeset: 100144:650cf38fba28 branch: 2.7 parent: 100134:6f7b2b7a029a user: Martin Panter <vadmium+py(a)gmail.com> date: Wed Feb 03 07:06:33 2016 +0000 summary: Issue #26244: Clarify default zlib compression level in documentation Based on patch by Aviv Palivoda. files: Doc/library/zlib.rst | 6 ++++-- Misc/ACKS | 1 + Modules/zlibmodule.c | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/Doc/library/zlib.rst b/Doc/library/zlib.rst --- a/Doc/library/zlib.rst +++ b/Doc/library/zlib.rst @@ -71,10 +71,12 @@ .. function:: compressobj([level[, method[, wbits[, memlevel[, strategy]]]]]) Returns a compression object, to be used for compressing data streams that won't - fit into memory at once. *level* is an integer from ``0`` to ``9`` controlling + fit into memory at once. *level* is an integer from + ``0`` to ``9`` or ``-1``, controlling the level of compression; ``1`` is fastest and produces the least compression, ``9`` is slowest and produces the most. ``0`` is no compression. The default - value is ``6``. + value is ``-1`` (Z_DEFAULT_COMPRESSION). Z_DEFAULT_COMPRESSION represents a default + compromise between speed and compression (currently equivalent to level 6). *method* is the compression algorithm. Currently, the only supported value is ``DEFLATED``. diff --git a/Misc/ACKS b/Misc/ACKS --- a/Misc/ACKS +++ b/Misc/ACKS @@ -1019,6 +1019,7 @@ Martin Packman Shriphani Palakodety Julien Palard +Aviv Palivoda Ondrej Palkovsky Mike Pall Todd R. Palmer diff --git a/Modules/zlibmodule.c b/Modules/zlibmodule.c --- a/Modules/zlibmodule.c +++ b/Modules/zlibmodule.c @@ -101,7 +101,7 @@ PyDoc_STRVAR(compressobj__doc__, "compressobj([level]) -- Return a compressor object.\n" "\n" -"Optional arg level is the compression level, in 0-9."); +"Optional arg level is the compression level, in 0-9 or -1."); PyDoc_STRVAR(decompressobj__doc__, "decompressobj([wbits]) -- Return a decompressor object.\n" -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 3.5 -> default): Issue #26244: Merge zlib documentation from 3.5
by martin.panter 02 Feb '16

02 Feb '16

https://hg.python.org/cpython/rev/03708c680eca changeset: 100146:03708c680eca parent: 100143:76624d47ee99 parent: 100145:950e0bfe94ae user: Martin Panter <vadmium+py(a)gmail.com> date: Wed Feb 03 07:52:06 2016 +0000 summary: Issue #26244: Merge zlib documentation from 3.5 files: Doc/library/zlib.rst | 7 ++++--- Misc/ACKS | 1 + Modules/clinic/zlibmodule.c.h | 7 ++++--- Modules/zlibmodule.c | 7 ++++--- 4 files changed, 13 insertions(+), 9 deletions(-) diff --git a/Doc/library/zlib.rst b/Doc/library/zlib.rst --- a/Doc/library/zlib.rst +++ b/Doc/library/zlib.rst @@ -60,10 +60,11 @@ Returns a compression object, to be used for compressing data streams that won't fit into memory at once. - *level* is the compression level -- an integer from ``0`` to ``9``. A value - of ``1`` is fastest and produces the least compression, while a value of + *level* is the compression level -- an integer from ``0`` to ``9`` or ``-1``. + A value of ``1`` is fastest and produces the least compression, while a value of ``9`` is slowest and produces the most. ``0`` is no compression. The default - value is ``6``. + value is ``-1`` (Z_DEFAULT_COMPRESSION). Z_DEFAULT_COMPRESSION represents a default + compromise between speed and compression (currently equivalent to level 6). *method* is the compression algorithm. Currently, the only supported value is ``DEFLATED``. diff --git a/Misc/ACKS b/Misc/ACKS --- a/Misc/ACKS +++ b/Misc/ACKS @@ -1075,6 +1075,7 @@ Martin Packman Shriphani Palakodety Julien Palard +Aviv Palivoda Ondrej Palkovsky Mike Pall Todd R. Palmer diff --git a/Modules/clinic/zlibmodule.c.h b/Modules/clinic/zlibmodule.c.h --- a/Modules/clinic/zlibmodule.c.h +++ b/Modules/clinic/zlibmodule.c.h @@ -89,8 +89,9 @@ "Return a compressor object.\n" "\n" " level\n" -" The compression level (an integer in the range 0-9; default is 6).\n" -" Higher compression levels are slower, but produce smaller results.\n" +" The compression level (an integer in the range 0-9 or -1; default is\n" +" currently equivalent to 6). Higher compression levels are slower,\n" +" but produce smaller results.\n" " method\n" " The compression algorithm. If given, this must be DEFLATED.\n" " wbits\n" @@ -438,4 +439,4 @@ #ifndef ZLIB_COMPRESS_COPY_METHODDEF #define ZLIB_COMPRESS_COPY_METHODDEF #endif /* !defined(ZLIB_COMPRESS_COPY_METHODDEF) */ -/*[clinic end generated code: output=7734aec079550bc8 input=a9049054013a1b77]*/ +/*[clinic end generated code: output=cf81e1deae3af0ce input=a9049054013a1b77]*/ diff --git a/Modules/zlibmodule.c b/Modules/zlibmodule.c --- a/Modules/zlibmodule.c +++ b/Modules/zlibmodule.c @@ -390,8 +390,9 @@ zlib.compressobj level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION - The compression level (an integer in the range 0-9; default is 6). - Higher compression levels are slower, but produce smaller results. + The compression level (an integer in the range 0-9 or -1; default is + currently equivalent to 6). Higher compression levels are slower, + but produce smaller results. method: int(c_default="DEFLATED") = DEFLATED The compression algorithm. If given, this must be DEFLATED. wbits: int(c_default="MAX_WBITS") = MAX_WBITS @@ -413,7 +414,7 @@ static PyObject * zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict) -/*[clinic end generated code: output=2949bbb9a5723ccd input=b034847f8821f6af]*/ +/*[clinic end generated code: output=2949bbb9a5723ccd input=de2ffab6e910cd8b]*/ { compobject *self = NULL; int err; -- Repository URL: https://hg.python.org/cpython

1 0

cpython (3.5): Issue #26244: Clarify default zlib compression level in documentation
by martin.panter 02 Feb '16

02 Feb '16

https://hg.python.org/cpython/rev/950e0bfe94ae changeset: 100145:950e0bfe94ae branch: 3.5 parent: 100141:7dabb94bdf63 user: Martin Panter <vadmium+py(a)gmail.com> date: Wed Feb 03 07:06:33 2016 +0000 summary: Issue #26244: Clarify default zlib compression level in documentation Based on patch by Aviv Palivoda. files: Doc/library/zlib.rst | 7 ++++--- Misc/ACKS | 1 + Modules/clinic/zlibmodule.c.h | 7 ++++--- Modules/zlibmodule.c | 7 ++++--- 4 files changed, 13 insertions(+), 9 deletions(-) diff --git a/Doc/library/zlib.rst b/Doc/library/zlib.rst --- a/Doc/library/zlib.rst +++ b/Doc/library/zlib.rst @@ -60,10 +60,11 @@ Returns a compression object, to be used for compressing data streams that won't fit into memory at once. - *level* is the compression level -- an integer from ``0`` to ``9``. A value - of ``1`` is fastest and produces the least compression, while a value of + *level* is the compression level -- an integer from ``0`` to ``9`` or ``-1``. + A value of ``1`` is fastest and produces the least compression, while a value of ``9`` is slowest and produces the most. ``0`` is no compression. The default - value is ``6``. + value is ``-1`` (Z_DEFAULT_COMPRESSION). Z_DEFAULT_COMPRESSION represents a default + compromise between speed and compression (currently equivalent to level 6). *method* is the compression algorithm. Currently, the only supported value is ``DEFLATED``. diff --git a/Misc/ACKS b/Misc/ACKS --- a/Misc/ACKS +++ b/Misc/ACKS @@ -1071,6 +1071,7 @@ Martin Packman Shriphani Palakodety Julien Palard +Aviv Palivoda Ondrej Palkovsky Mike Pall Todd R. Palmer diff --git a/Modules/clinic/zlibmodule.c.h b/Modules/clinic/zlibmodule.c.h --- a/Modules/clinic/zlibmodule.c.h +++ b/Modules/clinic/zlibmodule.c.h @@ -89,8 +89,9 @@ "Return a compressor object.\n" "\n" " level\n" -" The compression level (an integer in the range 0-9; default is 6).\n" -" Higher compression levels are slower, but produce smaller results.\n" +" The compression level (an integer in the range 0-9 or -1; default is\n" +" currently equivalent to 6). Higher compression levels are slower,\n" +" but produce smaller results.\n" " method\n" " The compression algorithm. If given, this must be DEFLATED.\n" " wbits\n" @@ -438,4 +439,4 @@ #ifndef ZLIB_COMPRESS_COPY_METHODDEF #define ZLIB_COMPRESS_COPY_METHODDEF #endif /* !defined(ZLIB_COMPRESS_COPY_METHODDEF) */ -/*[clinic end generated code: output=7734aec079550bc8 input=a9049054013a1b77]*/ +/*[clinic end generated code: output=cf81e1deae3af0ce input=a9049054013a1b77]*/ diff --git a/Modules/zlibmodule.c b/Modules/zlibmodule.c --- a/Modules/zlibmodule.c +++ b/Modules/zlibmodule.c @@ -390,8 +390,9 @@ zlib.compressobj level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION - The compression level (an integer in the range 0-9; default is 6). - Higher compression levels are slower, but produce smaller results. + The compression level (an integer in the range 0-9 or -1; default is + currently equivalent to 6). Higher compression levels are slower, + but produce smaller results. method: int(c_default="DEFLATED") = DEFLATED The compression algorithm. If given, this must be DEFLATED. wbits: int(c_default="MAX_WBITS") = MAX_WBITS @@ -413,7 +414,7 @@ static PyObject * zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict) -/*[clinic end generated code: output=2949bbb9a5723ccd input=b034847f8821f6af]*/ +/*[clinic end generated code: output=2949bbb9a5723ccd input=de2ffab6e910cd8b]*/ { compobject *self = NULL; int err; -- Repository URL: https://hg.python.org/cpython

1 0

cpython: Issue #24421: Compile _math.c separately to avoid race condition
by martin.panter 01 Feb '16

01 Feb '16

https://hg.python.org/cpython/rev/76624d47ee99 changeset: 100143:76624d47ee99 user: Martin Panter <vadmium+py(a)gmail.com> date: Wed Feb 03 05:19:44 2016 +0000 summary: Issue #24421: Compile _math.c separately to avoid race condition files: Makefile.pre.in | 6 +++++- Misc/NEWS | 4 ++++ setup.py | 12 ++++++++---- 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/Makefile.pre.in b/Makefile.pre.in --- a/Makefile.pre.in +++ b/Makefile.pre.in @@ -586,11 +586,15 @@ exit 1 ; \ fi +# This is shared by the math and cmath modules +Modules/_math.o: Modules/_math.c Modules/_math.h + $(CC) -c $(CCSHARED) $(PY_CORE_CFLAGS) -o $@ $< + # Build the shared modules # Under GNU make, MAKEFLAGS are sorted and normalized; the 's' for # -s, --silent or --quiet is always the first char. # Under BSD make, MAKEFLAGS might be " -s -v x=y". -sharedmods: $(BUILDPYTHON) pybuilddir.txt +sharedmods: $(BUILDPYTHON) pybuilddir.txt Modules/_math.o @case "$$MAKEFLAGS" in \ *\ -s*|s*) quiet="-q";; \ *) quiet="";; \ diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -671,6 +671,10 @@ - Issue #24986: It is now possible to build Python on Windows without errors when external libraries are not available. +- Issue #24421: Compile Modules/_math.c once, before building extensions. + Previously it could fail to compile properly if the math and cmath builds + were concurrent. + - Issue #25798: Update OS X 10.5 installer to use OpenSSL 1.0.2e. Windows diff --git a/setup.py b/setup.py --- a/setup.py +++ b/setup.py @@ -582,13 +582,17 @@ # array objects exts.append( Extension('array', ['arraymodule.c']) ) + + shared_math = 'Modules/_math.o' # complex math library functions - exts.append( Extension('cmath', ['cmathmodule.c', '_math.c'], - depends=['_math.h'], + exts.append( Extension('cmath', ['cmathmodule.c'], + extra_objects=[shared_math], + depends=['_math.h', shared_math], libraries=math_libs) ) # math library functions, e.g. sin() - exts.append( Extension('math', ['mathmodule.c', '_math.c'], - depends=['_math.h'], + exts.append( Extension('math', ['mathmodule.c'], + extra_objects=[shared_math], + depends=['_math.h', shared_math], libraries=math_libs) ) # time libraries: librt may be needed for clock_gettime() -- Repository URL: https://hg.python.org/cpython

1 0

cpython: merge
by raymond.hettinger 01 Feb '16

01 Feb '16

https://hg.python.org/cpython/rev/0731f097157b changeset: 100142:0731f097157b parent: 100140:c7f1acdd8be1 user: Raymond Hettinger <python(a)rcn.com> date: Mon Feb 01 21:21:19 2016 -0800 summary: merge files: Doc/library/collections.rst | 4 ++-- Lib/test/test_deque.py | 23 ++++++++++++----------- Modules/_collectionsmodule.c | 7 ++----- 3 files changed, 16 insertions(+), 18 deletions(-) diff --git a/Doc/library/collections.rst b/Doc/library/collections.rst --- a/Doc/library/collections.rst +++ b/Doc/library/collections.rst @@ -477,8 +477,8 @@ Insert *x* into the deque at position *i*. - If the insertion causes a bounded deque to grow beyond *maxlen*, the - rightmost element is then removed to restore the size limit. + If the insertion would cause a bounded deque to grow beyond *maxlen*, + an :exc:`IndexError` is raised. .. versionadded:: 3.5 diff --git a/Lib/test/test_deque.py b/Lib/test/test_deque.py --- a/Lib/test/test_deque.py +++ b/Lib/test/test_deque.py @@ -304,19 +304,20 @@ s.insert(i, 'Z') self.assertEqual(list(d), s) - def test_index_bug_26194(self): + def test_insert_bug_26194(self): data = 'ABC' - for i in range(len(data) + 1): - d = deque(data, len(data)) - d.insert(i, None) - s = list(data) - s.insert(i, None) - s.pop() - self.assertEqual(list(d), s) - if i < len(data): - self.assertIsNone(d[i]) + d = deque(data, maxlen=len(data)) + with self.assertRaises(IndexError): + d.insert(2, None) + + elements = 'ABCDEFGHI' + for i in range(-len(elements), len(elements)): + d = deque(elements, maxlen=len(elements)+1) + d.insert(i, 'Z') + if i >= 0: + self.assertEqual(d[i], 'Z') else: - self.assertTrue(None not in d) + self.assertEqual(d[i-1], 'Z') def test_imul(self): for n in (-10, -1, 0, 1, 2, 10, 1000): diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c --- a/Modules/_collectionsmodule.c +++ b/Modules/_collectionsmodule.c @@ -1085,16 +1085,13 @@ Py_ssize_t index; Py_ssize_t n = Py_SIZE(deque); PyObject *value; - PyObject *oldvalue; PyObject *rv; if (!PyArg_ParseTuple(args, "nO:insert", &index, &value)) return NULL; if (deque->maxlen == Py_SIZE(deque)) { - if (index >= deque->maxlen || Py_SIZE(deque) == 0) - Py_RETURN_NONE; - oldvalue = deque_pop(deque, NULL); - Py_DECREF(oldvalue); + PyErr_SetString(PyExc_IndexError, "deque already at its maximum size"); + return NULL; } if (index >= n) return deque_append(deque, value); -- Repository URL: https://hg.python.org/cpython

1 0

cpython (3.5): Issue #26194: Inserting into a full deque to raise an IndexError
by raymond.hettinger 01 Feb '16

01 Feb '16

https://hg.python.org/cpython/rev/7dabb94bdf63 changeset: 100141:7dabb94bdf63 branch: 3.5 parent: 100139:97c80e317ab8 user: Raymond Hettinger <python(a)rcn.com> date: Mon Feb 01 21:19:22 2016 -0800 summary: Issue #26194: Inserting into a full deque to raise an IndexError files: Doc/library/collections.rst | 4 ++-- Lib/test/test_deque.py | 23 ++++++++++++----------- Misc/NEWS | 4 ++-- Modules/_collectionsmodule.c | 7 ++----- 4 files changed, 18 insertions(+), 20 deletions(-) diff --git a/Doc/library/collections.rst b/Doc/library/collections.rst --- a/Doc/library/collections.rst +++ b/Doc/library/collections.rst @@ -477,8 +477,8 @@ Insert *x* into the deque at position *i*. - If the insertion causes a bounded deque to grow beyond *maxlen*, the - rightmost element is then removed to restore the size limit. + If the insertion would cause a bounded deque to grow beyond *maxlen*, + an :exc:`IndexError` is raised. .. versionadded:: 3.5 diff --git a/Lib/test/test_deque.py b/Lib/test/test_deque.py --- a/Lib/test/test_deque.py +++ b/Lib/test/test_deque.py @@ -304,19 +304,20 @@ s.insert(i, 'Z') self.assertEqual(list(d), s) - def test_index_bug_26194(self): + def test_insert_bug_26194(self): data = 'ABC' - for i in range(len(data) + 1): - d = deque(data, len(data)) - d.insert(i, None) - s = list(data) - s.insert(i, None) - s.pop() - self.assertEqual(list(d), s) - if i < len(data): - self.assertIsNone(d[i]) + d = deque(data, maxlen=len(data)) + with self.assertRaises(IndexError): + d.insert(2, None) + + elements = 'ABCDEFGHI' + for i in range(-len(elements), len(elements)): + d = deque(elements, maxlen=len(elements)+1) + d.insert(i, 'Z') + if i >= 0: + self.assertEqual(d[i], 'Z') else: - self.assertTrue(None not in d) + self.assertEqual(d[i-1], 'Z') def test_imul(self): for n in (-10, -1, 0, 1, 2, 10, 1000): diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -22,8 +22,8 @@ compiler issues. - Issue #26194: Deque.insert() gave odd results for bounded deques that had - reached their maximum size. Now, the insert will happen normally and then - any overflowing element will be truncated from the right side. + reached their maximum size. Now an IndexError will be raised when attempting + to insert into a full deque. - Issue #25843: When compiling code, don't merge constants if they are equal but have a different types. For example, ``f1, f2 = lambda: 1, lambda: 1.0`` diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c --- a/Modules/_collectionsmodule.c +++ b/Modules/_collectionsmodule.c @@ -973,16 +973,13 @@ Py_ssize_t index; Py_ssize_t n = Py_SIZE(deque); PyObject *value; - PyObject *oldvalue; PyObject *rv; if (!PyArg_ParseTuple(args, "nO:insert", &index, &value)) return NULL; if (deque->maxlen == Py_SIZE(deque)) { - if (index >= deque->maxlen || Py_SIZE(deque) == 0) - Py_RETURN_NONE; - oldvalue = deque_pop(deque, NULL); - Py_DECREF(oldvalue); + PyErr_SetString(PyExc_IndexError, "deque already at its maximum size"); + return NULL; } if (index >= n) return deque_append(deque, value); -- Repository URL: https://hg.python.org/cpython

1 0

NEUTRAL Benchmark Results for Python 2.7 2016-02-01
by lp_benchmark_robot＠intel.com 01 Feb '16

01 Feb '16

Results for project Python 2.7, build date 2016-02-01 03:59:51 +0000 commit: 296fb7c10a7d previous commit: 14463726a4a0 revision date: 2016-01-30 01:06:00 +0000 environment: Haswell-EP cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem: 128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release v2.7.10, with hash 15c95b7d81dc from 2015-05-23 16:02:14+00:00 ---------------------------------------------------------------------------------- benchmark relative change since change since current rev run std_dev* last run baseline with PGO ---------------------------------------------------------------------------------- :-| django_v2 0.42% -0.53% 1.63% 6.94% :-) pybench 0.17% 0.01% 6.07% 4.03% :-( regex_v8 0.58% 0.16% -2.36% 11.07% :-) nbody 0.14% -0.03% 8.02% 1.06% :-) json_dump_v2 0.26% -0.02% 4.67% 11.74% :-( normal_startup 2.17% -0.76% -5.85% 2.57% :-| ssbench 0.21% -0.16% 0.91% 2.18% ---------------------------------------------------------------------------------- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-python-… Note: Benchmark results for ssbench are measured in requests/second while all other are measured in seconds. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the Python project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration.

1 0