Mailman 3 January 2016 - Python-checkins

Daily reference leaks (c080ef5989f7): sum=4
by solipsis＠pitrou.net Jan. 30, 2016

Jan. 30, 2016

results for c080ef5989f7 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/reflogUt90PB', '--timeout', '7200']

1 0

peps: PEP 513: Cover unicode ABI compatibility
by nick.coghlan Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/peps/rev/7a2528c908d4 changeset: 6216:7a2528c908d4 user: Nick Coghlan <ncoghlan(a)gmail.com> date: Sat Jan 30 18:45:54 2016 +1000 summary: PEP 513: Cover unicode ABI compatibility files: pep-0513.txt | 43 ++++++++++++++++++++++++++------------- 1 files changed, 28 insertions(+), 15 deletions(-) diff --git a/pep-0513.txt b/pep-0513.txt --- a/pep-0513.txt +++ b/pep-0513.txt @@ -151,8 +151,12 @@ libgthread-2.0.so.0 libglib-2.0.so.0 -… [View More]and (b), work on a stock CentOS 5.11 [6]_ system that contains the system -package manager's provided versions of these libraries. +and, (b) work on a stock CentOS 5.11 [6]_ system that contains the system +package manager's provided versions of these libraries. In addition, +for wheels targeting CPython 3.2 and earlier (including all 2.x +versions), there is an extra requirement that (c) the wheel be +built against a version of CPython compiled with 4-byte unicode +support (i.e. one where ``sys.maxunicode > 0xFFFF``). Because CentOS 5 is only available for x86_64 and i386 architectures, these are the only architectures currently supported by the ``manylinux1`` @@ -344,9 +348,11 @@ that a system *is* compatible, unless there is specific reason to think otherwise. -We know of three main sources of potential incompatibility that are likely to -arise in practice: +We know of four main sources of potential incompatibility that are +likely to arise in practice: +* "Narrow" unicode builds of Python 3.2 and earlier (including all + versions of Python 2) * Eventually, in the future, there may exist distributions that break compatibility with this profile (e.g., if one of the libraries in the profile changes its ABI in a backwards-incompatible way) @@ -354,20 +360,22 @@ * A linux distribution that does not use ``glibc`` (e.g. Alpine Linux, which is based on musl ``libc``, or Android) -Therefore, we propose a two-pronged approach. To catch the first -case, we standardize a mechanism for a Python distributor to signal -that a particular Python install definitely is or is not compatible -with ``manylinux1``: this is done by installing a module named -``_manylinux``, and setting its ``manylinux1_compatible`` -attribute. We do not propose adding any such module to the standard -library -- this is merely a well-known name by which distributors and -installation tools can rendezvous. However, if a distributor does add -this module, *they should add it to the standard library* rather than -to a ``site-packages/`` directory, because the standard library is +Checking for unicode configuration compatibility is straightforward, +but the other cases are more subtle. We propose a two-pronged +approach. To handle potential future incompatibilities, we standardize +a mechanism for a Python distributor to signal that a particular +Python install definitely is or is not compatible with ``manylinux1``: +this is done by installing a module named ``_manylinux``, and setting +its ``manylinux1_compatible`` attribute. We do not propose adding any +such module to the standard library -- this is merely a well-known +name by which distributors and installation tools can +rendezvous. However, if a distributor does add this module, *they +should add it to the standard library* rather than to a +``site-packages/`` directory, because the standard library is inherited by virtualenvs (which we want), and ``site-packages/`` in general is not. -Then, to handle the latter two cases for existing Python +Then, to handle the last two cases for existing Python distributions, we suggest a simple and reliable method to check for the presence and version of ``glibc`` (basically using it as a "clock" for the overall age of the distribution). @@ -380,6 +388,11 @@ if get_platform() not in ["linux_x86_64", "linux_i386"]: return False + # "wide" Unicode mode is mandatory (always true on CPython 3.3+) + import sys + if sys.maxunicode <= 0xFFFF: + return False + # Check for presence of _manylinux module try: import _manylinux -- Repository URL: https://hg.python.org/peps [View Less]

1 0

peps: PEP 513: latest update from Nathaniel
by nick.coghlan Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/peps/rev/0f0d8f47efa4 changeset: 6215:0f0d8f47efa4 user: Nick Coghlan <ncoghlan(a)gmail.com> date: Sat Jan 30 17:10:13 2016 +1000 summary: PEP 513: latest update from Nathaniel files: pep-0513.txt | 106 ++++++++++++++++++++++++++++---------- 1 files changed, 77 insertions(+), 29 deletions(-) diff --git a/pep-0513.txt b/pep-0513.txt --- a/pep-0513.txt +++ b/pep-0513.txt @@ -9,7 +9,7 @@ Type: Informational Content-Type: text/x-rst Created: … [View More]19-Jan-2016 -Post-History: 19-Jan-2016, 25-Jan-2016 +Post-History: 19-Jan-2016, 25-Jan-2016, 29-Jan-2016 Abstract @@ -240,7 +240,7 @@ Auditwheel ---------- -The second tools is a command line executable called ``auditwheel`` [10]_ that +The second tool is a command line executable called ``auditwheel`` [10]_ that may aid in package maintainers in dealing with third-party external dependencies. @@ -347,31 +347,69 @@ We know of three main sources of potential incompatibility that are likely to arise in practice: +* Eventually, in the future, there may exist distributions that break + compatibility with this profile (e.g., if one of the libraries in + the profile changes its ABI in a backwards-incompatible way) * A linux distribution that is too old (e.g. RHEL 4) * A linux distribution that does not use ``glibc`` (e.g. Alpine Linux, which is based on musl ``libc``, or Android) -* Eventually, in the future, there may exist distributions that break - compatibility with this profile -To handle the first two cases, we propose the following simple and reliable -check: :: +Therefore, we propose a two-pronged approach. To catch the first +case, we standardize a mechanism for a Python distributor to signal +that a particular Python install definitely is or is not compatible +with ``manylinux1``: this is done by installing a module named +``_manylinux``, and setting its ``manylinux1_compatible`` +attribute. We do not propose adding any such module to the standard +library -- this is merely a well-known name by which distributors and +installation tools can rendezvous. However, if a distributor does add +this module, *they should add it to the standard library* rather than +to a ``site-packages/`` directory, because the standard library is +inherited by virtualenvs (which we want), and ``site-packages/`` in +general is not. - def have_glibc_version(major, minimum_minor): +Then, to handle the latter two cases for existing Python +distributions, we suggest a simple and reliable method to check for +the presence and version of ``glibc`` (basically using it as a "clock" +for the overall age of the distribution). + +Specifically, the algorithm we propose is:: + + def is_manylinux1_compatible(): + # Only Linux, and only x86-64 / i386 + from distutils.util import get_platform + if get_platform() not in ["linux_x86_64", "linux_i386"]: + return False + + # Check for presence of _manylinux module + try: + import _manylinux + return bool(_manylinux.manylinux1_compatible) + except (ImportError, AttributeError): + # Fall through to heuristic check below + pass + + # Check glibc version. CentOS 5 uses glibc 2.5. + return have_compatible_glibc(2, 5) + + def have_compatible_glibc(major, minimum_minor): import ctypes process_namespace = ctypes.CDLL(None) try: gnu_get_libc_version = process_namespace.gnu_get_libc_version except AttributeError: - # We are not linked to glibc. + # Symbol doesn't exist -> therefore, we are not linked to + # glibc. return False + # Call gnu_get_libc_version, which returns a string like "2.5". gnu_get_libc_version.restype = ctypes.c_char_p version_str = gnu_get_libc_version() # py2 / py3 compatibility: if not isinstance(version_str, str): version_str = version_str.decode("ascii") + # Parse string and check against requested version. version = [int(piece) for piece in version_str.split(".")] assert len(version) == 2 if major != version[0]: @@ -380,30 +418,40 @@ return False return True - # CentOS 5 uses glibc 2.5. - is_manylinux1_compatible = have_glibc_version(2, 5) +**Rejected alternatives:** We also considered using a configuration +file, e.g. ``/etc/python/compatibility.cfg``. The problem with this is +that a single filesystem might contain many different interpreter +environments, each with their own ABI profile -- the ``manylinux1`` +compatibility of a system-installed x86_64 CPython might not tell us +much about the ``manylinux1`` compatibility of a user-installed i386 +PyPy. Locating this configuration information within the Python +environment itself ensures that it remains attached to the correct +binary, and dramatically simplifies lookup code. -To handle the third case, we propose the creation of a file -``/etc/python/compatibility.cfg`` in ConfigParser format, with sample -contents: :: +We also considered using a more elaborate structure, like a list of +all platform tags that should be considered compatible, together with +their preference ordering, for example: ``_binary_compat.compatible = +["manylinux1_x86_64", "centos5_x86_64", "linux_x86_64"]``. However, +this introduces several complications. For example, we want to be able +to distinguish between the state of "doesn't support ``manylinux1``" +(or eventually ``manylinux2``, etc.) versus "doesn't specify either +way whether it supports ``manylinux1``", which is not entirely obvious +in the above representation; and, it's not at all clear what features +are really needed vis a vis preference ordering given that right now +the only possible platform tags are ``manylinux1`` and ``linux``. So +we're deferring a more complete solution here for a separate PEP, when +/ if Linux gets more platform tags. - [manylinux1] - compatible = true +For the library compatibility check, we also considered much more +elaborate checks (e.g. checking the kernel version, searching for and +checking the versions of all the individual libraries listed in the +``manylinux1`` profile, etc.), but ultimately decided that this would +be more likely to introduce confusing bugs than actually help the +user. (For example: different distributions vary in where they +actually put these libraries, and if our checking code failed to use +the correct path search then it could easily return incorrect +answers.) -where the supported values for the ``manylinux1.compatible`` entry are the -same as those supported by the ConfigParser ``getboolean`` method. - -The proposed logic for ``pip`` or related tools, then, is: - -0) If ``distutils.util.get_platform()`` does not start with the string - ``"linux"``, then assume the current system is not ``manylinux1`` - compatible. -1) If ``/etc/python/compatibility.conf`` exists and contains a ``manylinux1`` - key, then trust that. -2) Otherwise, if ``have_glibc_version(2, 5)`` returns true, then assume the - current system can handle ``manylinux1`` wheels. -3) Otherwise, assume that the current system cannot handle ``manylinux1`` - wheels. PyPI Support -- Repository URL: https://hg.python.org/peps [View Less]

1 0

cpython (merge 3.5 -> default): Issue #4806: Merge * unpacking fix from 3.5
by martin.panter Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/cpython/rev/1261f5f6fc95 changeset: 100117:1261f5f6fc95 parent: 100115:c080ef5989f7 parent: 100116:1a8dc350962b user: Martin Panter <vadmium+py(a)gmail.com> date: Sun Jan 31 06:33:16 2016 +0000 summary: Issue #4806: Merge * unpacking fix from 3.5 files: Lib/test/test_extcall.py | 49 +++++++++++++++++++++++++-- Misc/NEWS | 4 ++ Python/ceval.c | 18 +++++---- 3 files changed, 58 insertions(+), 13 … [View More]deletions(-) diff --git a/Lib/test/test_extcall.py b/Lib/test/test_extcall.py --- a/Lib/test/test_extcall.py +++ b/Lib/test/test_extcall.py @@ -114,7 +114,7 @@ >>> g(*Nothing()) Traceback (most recent call last): ... - TypeError: g() argument after * must be a sequence, not Nothing + TypeError: g() argument after * must be an iterable, not Nothing >>> class Nothing: ... def __len__(self): return 5 @@ -123,7 +123,7 @@ >>> g(*Nothing()) Traceback (most recent call last): ... - TypeError: g() argument after * must be a sequence, not Nothing + TypeError: g() argument after * must be an iterable, not Nothing >>> class Nothing(): ... def __len__(self): return 5 @@ -149,6 +149,45 @@ >>> g(*Nothing()) 0 (1, 2, 3) {} +Check for issue #4806: Does a TypeError in a generator get propagated with the +right error message? (Also check with other iterables.) + + >>> def broken(): raise TypeError("myerror") + ... + + >>> g(*(broken() for i in range(1))) + Traceback (most recent call last): + ... + TypeError: myerror + + >>> class BrokenIterable1: + ... def __iter__(self): + ... raise TypeError('myerror') + ... + >>> g(*BrokenIterable1()) + Traceback (most recent call last): + ... + TypeError: myerror + + >>> class BrokenIterable2: + ... def __iter__(self): + ... yield 0 + ... raise TypeError('myerror') + ... + >>> g(*BrokenIterable2()) + Traceback (most recent call last): + ... + TypeError: myerror + + >>> class BrokenSequence: + ... def __getitem__(self, idx): + ... raise TypeError('myerror') + ... + >>> g(*BrokenSequence()) + Traceback (most recent call last): + ... + TypeError: myerror + Make sure that the function doesn't stomp the dictionary >>> d = {'a': 1, 'b': 2, 'c': 3} @@ -188,17 +227,17 @@ >>> h(*h) Traceback (most recent call last): ... - TypeError: h() argument after * must be a sequence, not function + TypeError: h() argument after * must be an iterable, not function >>> dir(*h) Traceback (most recent call last): ... - TypeError: dir() argument after * must be a sequence, not function + TypeError: dir() argument after * must be an iterable, not function >>> None(*h) Traceback (most recent call last): ... - TypeError: NoneType object argument after * must be a sequence, \ + TypeError: NoneType object argument after * must be an iterable, \ not function >>> h(**h) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -10,6 +10,10 @@ Core and Builtins ----------------- +- Issue #4806: Avoid masking the original TypeError exception when using star + (*) unpacking in function calls. Based on patch by Hagen Fürstenau and + Daniel Urban. + - Issue #26146: Add a new kind of AST node: ``ast.Constant``. It can be used by external AST optimizers, but the compiler does not emit directly such node. diff --git a/Python/ceval.c b/Python/ceval.c --- a/Python/ceval.c +++ b/Python/ceval.c @@ -4999,16 +4999,18 @@ stararg = EXT_POP(*pp_stack); if (!PyTuple_Check(stararg)) { PyObject *t = NULL; + if (Py_TYPE(stararg)->tp_iter == NULL && + !PySequence_Check(stararg)) { + PyErr_Format(PyExc_TypeError, + "%.200s%.200s argument after * " + "must be an iterable, not %.200s", + PyEval_GetFuncName(func), + PyEval_GetFuncDesc(func), + stararg->ob_type->tp_name); + goto ext_call_fail; + } t = PySequence_Tuple(stararg); if (t == NULL) { - if (PyErr_ExceptionMatches(PyExc_TypeError)) { - PyErr_Format(PyExc_TypeError, - "%.200s%.200s argument after * " - "must be a sequence, not %.200s", - PyEval_GetFuncName(func), - PyEval_GetFuncDesc(func), - stararg->ob_type->tp_name); - } goto ext_call_fail; } Py_DECREF(stararg); -- Repository URL: https://hg.python.org/cpython [View Less]

1 0

cpython (3.5): Issue #4806: Avoid masking original TypeError in call with * unpacking
by martin.panter Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/cpython/rev/1a8dc350962b changeset: 100116:1a8dc350962b branch: 3.5 parent: 100114:747b415e96c4 user: Martin Panter <vadmium+py(a)gmail.com> date: Sun Jan 31 06:30:56 2016 +0000 summary: Issue #4806: Avoid masking original TypeError in call with * unpacking Based on patch by Hagen Fürstenau and Daniel Urban. files: Lib/test/test_extcall.py | 49 +++++++++++++++++++++++++-- Misc/NEWS | 4 ++ Python/ceval.c |… [View More] 18 +++++---- 3 files changed, 58 insertions(+), 13 deletions(-) diff --git a/Lib/test/test_extcall.py b/Lib/test/test_extcall.py --- a/Lib/test/test_extcall.py +++ b/Lib/test/test_extcall.py @@ -114,7 +114,7 @@ >>> g(*Nothing()) Traceback (most recent call last): ... - TypeError: g() argument after * must be a sequence, not Nothing + TypeError: g() argument after * must be an iterable, not Nothing >>> class Nothing: ... def __len__(self): return 5 @@ -123,7 +123,7 @@ >>> g(*Nothing()) Traceback (most recent call last): ... - TypeError: g() argument after * must be a sequence, not Nothing + TypeError: g() argument after * must be an iterable, not Nothing >>> class Nothing(): ... def __len__(self): return 5 @@ -149,6 +149,45 @@ >>> g(*Nothing()) 0 (1, 2, 3) {} +Check for issue #4806: Does a TypeError in a generator get propagated with the +right error message? (Also check with other iterables.) + + >>> def broken(): raise TypeError("myerror") + ... + + >>> g(*(broken() for i in range(1))) + Traceback (most recent call last): + ... + TypeError: myerror + + >>> class BrokenIterable1: + ... def __iter__(self): + ... raise TypeError('myerror') + ... + >>> g(*BrokenIterable1()) + Traceback (most recent call last): + ... + TypeError: myerror + + >>> class BrokenIterable2: + ... def __iter__(self): + ... yield 0 + ... raise TypeError('myerror') + ... + >>> g(*BrokenIterable2()) + Traceback (most recent call last): + ... + TypeError: myerror + + >>> class BrokenSequence: + ... def __getitem__(self, idx): + ... raise TypeError('myerror') + ... + >>> g(*BrokenSequence()) + Traceback (most recent call last): + ... + TypeError: myerror + Make sure that the function doesn't stomp the dictionary >>> d = {'a': 1, 'b': 2, 'c': 3} @@ -188,17 +227,17 @@ >>> h(*h) Traceback (most recent call last): ... - TypeError: h() argument after * must be a sequence, not function + TypeError: h() argument after * must be an iterable, not function >>> dir(*h) Traceback (most recent call last): ... - TypeError: dir() argument after * must be a sequence, not function + TypeError: dir() argument after * must be an iterable, not function >>> None(*h) Traceback (most recent call last): ... - TypeError: NoneType object argument after * must be a sequence, \ + TypeError: NoneType object argument after * must be an iterable, \ not function >>> h(**h) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -10,6 +10,10 @@ Core and Builtins ----------------- +- Issue #4806: Avoid masking the original TypeError exception when using star + (*) unpacking in function calls. Based on patch by Hagen Fürstenau and + Daniel Urban. + - Issue #26154: Add a new private _PyThreadState_UncheckedGet() function to get the current Python thread state, but don't issue a fatal error if it is NULL. This new function must be used instead of accessing directly the diff --git a/Python/ceval.c b/Python/ceval.c --- a/Python/ceval.c +++ b/Python/ceval.c @@ -4935,16 +4935,18 @@ stararg = EXT_POP(*pp_stack); if (!PyTuple_Check(stararg)) { PyObject *t = NULL; + if (Py_TYPE(stararg)->tp_iter == NULL && + !PySequence_Check(stararg)) { + PyErr_Format(PyExc_TypeError, + "%.200s%.200s argument after * " + "must be an iterable, not %.200s", + PyEval_GetFuncName(func), + PyEval_GetFuncDesc(func), + stararg->ob_type->tp_name); + goto ext_call_fail; + } t = PySequence_Tuple(stararg); if (t == NULL) { - if (PyErr_ExceptionMatches(PyExc_TypeError)) { - PyErr_Format(PyExc_TypeError, - "%.200s%.200s argument after * " - "must be a sequence, not %.200s", - PyEval_GetFuncName(func), - PyEval_GetFuncDesc(func), - stararg->ob_type->tp_name); - } goto ext_call_fail; } Py_DECREF(stararg); -- Repository URL: https://hg.python.org/cpython [View Less]

1 0

cpython (merge 3.5 -> default): Issue #25934: Merge with 3.5
by zach.ware Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/cpython/rev/c080ef5989f7 changeset: 100115:c080ef5989f7 parent: 100112:284b3de802b7 parent: 100114:747b415e96c4 user: Zachary Ware <zachary.ware(a)gmail.com> date: Fri Jan 29 19:09:41 2016 -0600 summary: Issue #25934: Merge with 3.5 files: PCbuild/pyproject.props | 3 +++ PCbuild/python.props | 16 +++++++++++----- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/PCbuild/pyproject.props b/PCbuild/pyproject.props -… [View More]-- a/PCbuild/pyproject.props +++ b/PCbuild/pyproject.props @@ -50,6 +50,9 @@ <WholeProgramOptimization>false</WholeProgramOptimization> <RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary> </ClCompile> + <ClCompile Condition="$(ICCBuild) == 'true'"> + <FloatingPointModel>Strict</FloatingPointModel> + </ClCompile> <Link> <AdditionalLibraryDirectories>$(OutDir);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories> <GenerateDebugInformation>true</GenerateDebugInformation> diff --git a/PCbuild/python.props b/PCbuild/python.props --- a/PCbuild/python.props +++ b/PCbuild/python.props @@ -7,12 +7,18 @@ Use the latest available version of Visual Studio to build. To override this and build with an earlier version, pass "/p:PlatformToolset=v100" (for example) when building. + + We set BasePlatformToolset for ICC's benefit, it's otherwise ignored. --> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath14)' != ''">v140</PlatformToolset> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath12)' != ''">v120</PlatformToolset> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath11)' != ''">v110</PlatformToolset> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath10)' != ''">v100</PlatformToolset> - + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath14)' != ''">v140</BasePlatformToolset> + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath12)' != ''">v120</BasePlatformToolset> + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath11)' != ''">v110</BasePlatformToolset> + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath10)' != ''">v100</BasePlatformToolset> + + <PlatformToolset Condition="'$(PlatformToolset)' == ''">$(BasePlatformToolset)</PlatformToolset> + <ICCBuild>false</ICCBuild> + <ICCBuild Condition="$(PlatformToolset.StartsWith(`Intel C++ Compiler`))">true</ICCBuild> + <!-- Convincing MSVC/MSBuild to prefer our platform names is too difficult, so we define our own constant ArchName and use wherever we need it. -- Repository URL: https://hg.python.org/cpython [View Less]

1 0

cpython (2.7): Issue #25934: Default to /fp:strict for ICC builds
by zach.ware Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/cpython/rev/296fb7c10a7d changeset: 100113:296fb7c10a7d branch: 2.7 parent: 100110:14463726a4a0 user: Zachary Ware <zachary.ware(a)gmail.com> date: Fri Jan 29 19:06:00 2016 -0600 summary: Issue #25934: Default to /fp:strict for ICC builds files: PCbuild/pyproject.props | 3 +++ PCbuild/python.props | 2 ++ 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/PCbuild/pyproject.props b/PCbuild/pyproject.props --- a/… [View More]

1 0

cpython (3.5): Issue #25934: Default to /fp:strict for ICC builds
by zach.ware Jan. 30, 2016

Jan. 30, 2016

https://hg.python.org/cpython/rev/747b415e96c4 changeset: 100114:747b415e96c4 branch: 3.5 parent: 100111:c75ae81b5058 user: Zachary Ware <zachary.ware(a)gmail.com> date: Fri Jan 29 19:08:55 2016 -0600 summary: Issue #25934: Default to /fp:strict for ICC builds files: PCbuild/pyproject.props | 3 +++ PCbuild/python.props | 16 +++++++++++----- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/PCbuild/pyproject.props b/PCbuild/pyproject.… [View More]props --- a/PCbuild/pyproject.props +++ b/PCbuild/pyproject.props @@ -50,6 +50,9 @@ <WholeProgramOptimization>false</WholeProgramOptimization> <RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary> </ClCompile> + <ClCompile Condition="$(ICCBuild) == 'true'"> + <FloatingPointModel>Strict</FloatingPointModel> + </ClCompile> <Link> <AdditionalLibraryDirectories>$(OutDir);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories> <GenerateDebugInformation>true</GenerateDebugInformation> diff --git a/PCbuild/python.props b/PCbuild/python.props --- a/PCbuild/python.props +++ b/PCbuild/python.props @@ -7,12 +7,18 @@ Use the latest available version of Visual Studio to build. To override this and build with an earlier version, pass "/p:PlatformToolset=v100" (for example) when building. + + We set BasePlatformToolset for ICC's benefit, it's otherwise ignored. --> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath14)' != ''">v140</PlatformToolset> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath12)' != ''">v120</PlatformToolset> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath11)' != ''">v110</PlatformToolset> - <PlatformToolset Condition="'$(PlatformToolset)' == '' and '$(VCTargetsPath10)' != ''">v100</PlatformToolset> - + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath14)' != ''">v140</BasePlatformToolset> + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath12)' != ''">v120</BasePlatformToolset> + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath11)' != ''">v110</BasePlatformToolset> + <BasePlatformToolset Condition="'$(BasePlatformToolset)' == '' and '$(VCTargetsPath10)' != ''">v100</BasePlatformToolset> + + <PlatformToolset Condition="'$(PlatformToolset)' == ''">$(BasePlatformToolset)</PlatformToolset> + <ICCBuild>false</ICCBuild> + <ICCBuild Condition="$(PlatformToolset.StartsWith(`Intel C++ Compiler`))">true</ICCBuild> + <!-- Convincing MSVC/MSBuild to prefer our platform names is too difficult, so we define our own constant ArchName and use wherever we need it. -- Repository URL: https://hg.python.org/cpython [View Less]

1 0

NEUTRAL Benchmark Results for Python 2.7 2016-01-29
by lp_benchmark_robot＠intel.com Jan. 29, 2016

Jan. 29, 2016

Results for project Python 2.7, build date 2016-01-29 03:59:48 +0000 commit: 14463726a4a0 previous commit: 34ca24fa1b4a revision date: 2016-01-30 02:36: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 ------------------------------------------------… [View More]---------------------------------- benchmark relative change since change since current rev run std_dev* last run baseline with PGO ---------------------------------------------------------------------------------- :-) django_v2 0.42% -0.16% 2.16% 6.06% :-) pybench 0.11% -0.01% 6.06% 5.13% :-( regex_v8 0.60% -0.11% -2.53% 10.53% :-) nbody 0.15% -0.94% 8.05% 3.94% :-) json_dump_v2 0.24% 0.88% 4.69% 12.50% :-( normal_startup 2.04% 0.07% -5.05% 2.35% :-| ssbench 0.11% -0.23% 1.07% 1.26% ---------------------------------------------------------------------------------- * 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. [View Less]

1 0

GOOD Benchmark Results for Python Default 2016-01-29
by lp_benchmark_robot＠intel.com Jan. 29, 2016

Jan. 29, 2016

Results for project Python default, build date 2016-01-29 03:08:10 +0000 commit: d5d0b62c2830 previous commit: 96c88daac37a revision date: 2016-01-28 19:43:51 +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 ---------------------------------------------… [View More]------------------------------------- benchmark relative change since change since current rev run std_dev* last run baseline with PGO ---------------------------------------------------------------------------------- :-) django_v2 0.17% 0.93% 8.80% 14.30% :-( pybench 0.15% -0.21% -2.47% 5.10% :-( regex_v8 2.72% 0.16% -4.74% 3.58% :-| nbody 0.12% 0.27% 0.35% 7.40% :-( json_dump_v2 0.18% 0.07% -2.07% 9.74% :-| normal_startup 0.80% 1.72% -0.24% 5.24% ---------------------------------------------------------------------------------- * 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. [View Less]

1 0