Staging
v0.5.0
https://github.com/python/cpython

sort by:
Revision Author Date Message Commit Date
c2f86d8 Empty blurb file for 2.7.17. 19 October 2019, 18:38:44 UTC
74ceb35 Bump version to 2.7.17 final. 19 October 2019, 18:37:52 UTC
6c4f841 Update doc switcher list for 3.8.0 (GH-16809) (cherry picked from commit 3f36043db22361500f52634f2b8de49dde0e7da9) Co-authored-by: Ned Deily <nad@python.org> 19 October 2019, 17:52:07 UTC
4ae38ba Update build docs for macOS (GH-16844) 19 October 2019, 09:35:44 UTC
dedb99a bpo-32758: Warn that ast.parse() and ast.literal_eval() can segfault the interpreter (GH-5960) (GH-16565) (cherry picked from commit 7a7f100eb352d08938ee0f5ba59c18f56dc4a7b5) Co-authored-by: Brett Cannon <brettcannon@users.noreply.github.com> 18 October 2019, 08:00:22 UTC
8eb27cc bpo-32758: Warn that compile() can crash when compiling to an AST object (GH-6043) (GH-16566) (cherry picked from commit f7a6ff6fcab32a53f262ba3f8a072c27afc330d7) Co-authored-by: Brett Cannon <brettcannon@users.noreply.github.com> 18 October 2019, 08:00:03 UTC
bef8d9a Doc: 3.8 is now stable. (GH-16790) (GH-16794) (cherry picked from commit 4504b4500d2a1a80c26b27b0bfff8b624d5ce06c) Co-authored-by: Julien Palard <julien@palard.fr> 14 October 2019, 22:22:18 UTC
2c9d70a [2.7] Update macOS installer display files for 2.7.17 (GH-16768) 14 October 2019, 08:39:00 UTC
0bd59d6 [2.7] bpo-31036: Allow sphinx and blurb to be found automatically (GH-16638) Rather than requiring the path to blurb and/or sphinx-build to be specified to the make rule, enhance the Doc/Makefile to look for each first in a virtual environment created by make venv and, if not found, look on the normal process PATH. This allows the Doc/Makefile to take advantage of an installed spinx-build or blurb and, thus, do the right thing most of the time. Also, make the directory for the venv be configurable and document the `make venv` target.. (cherry picked from commit 590665c399fc4aa3c4a9f8e7104d43a02e9f3a0c) Co-authored-by: Ned Deily <nad@python.org> 08 October 2019, 03:57:05 UTC
e78d79c bpo-35036: Remove empty log line in the suspicious.py tool (GH-10024) Previous to commit ee171a2 the logline was working because of self.info() (now deprecated) defaults to an empty message. (cherry picked from commit c3f52a59ce8406d9e59253ad4621e4749abdaeef) Co-authored-by: Xtreak <tirkarthi@users.noreply.github.com> 08 October 2019, 03:43:53 UTC
d9b3216 bpo-31589 : Build PDF using xelatex for better UTF8 support. (GH-3940) Also addresses doc build failures documented in bpo-32200. (cherry picked from commit 7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff) Co-authored-by: Julien Palard <julien@palard.fr> 08 October 2019, 03:42:51 UTC
c9a195e [2.7] Stop using deprecated logging API in Sphinx suspicious checker (GH-16635) (cherry picked from commit ee171a26c1169abfae534b08acc0d95c6e45a22a) Co-authored-by: Pablo Galindo <Pablogsal@gmail.com> 08 October 2019, 03:37:45 UTC
1c7b141 Update macOS installer displays for 2.7.17rc1 (#16634) 08 October 2019, 02:13:04 UTC
a6df224 Bump version to 2.7.17rc1. 08 October 2019, 02:03:32 UTC
89dea46 Roll up news for 2.7.17rc1. 08 October 2019, 02:01:18 UTC
f5b1abb [2.7] bpo-38216, bpo-36274: Allow subclasses to separately override validation and encoding behavior (GH-16476) Backporting this change, I observe a couple of things: 1. The _encode_request call is no longer meaningful because the request construction will implicitly encode the request using the default encoding when the format string is used (request = '%s %s %s'...). In order to keep the code as consistent as possible, I decided to include the call as a pass-through. I'd be just as happy to remove it entirely, but I'll leave that up to the reviewer to decide. It's okay that this functionality is disabled on Python 2 because this functionality was mainly around bpo-36274, which was mainly a concern with the transition to Python 3. 2. Because _encode_request is no longer meaningful, neither is the test for it, so I've removed that test. Therefore, the meaningful part of this test is that for bpo-38216, adding a (underscore-protected) hook to customize/disable validation. (cherry picked from commit 7774d7831e8809795c64ce27f7df52674581d298) Co-authored-by: Jason R. Coombs <jaraco@jaraco.com> 08 October 2019, 02:00:01 UTC
e7e58fe [2.7] bpo-37664: Update ensurepip bundled wheels, again (GH-16633) (cherry picked from commit 10c452b894d95fed06056fe11e8fe8e1a2a60040) Co-authored-by: Pradyun Gedam <pradyunsg@gmail.com> 08 October 2019, 01:54:05 UTC
c5abd63 bpo-38106: Fix race in pthread PyThread_release_lock() (GH-16047) Fix race in PyThread_release_lock that was leading to memory corruption and deadlocks. The fix applies to POSIX systems where Python locks are implemented with mutex and condition variable because POSIX semaphores are either not provided, or are known to be broken. One particular example of such system is macOS. On Darwin, even though this is considered as POSIX, Python uses mutex+condition variable to implement its lock, and, as of 2019-08-28, Py2.7 implementation, even though similar issue was fixed for Py3 in 2012, contains synchronization bug: the condition is signalled after mutex unlock while the correct protocol is to signal condition from under mutex: https://github.com/python/cpython/blob/v2.7.16-127-g0229b56d8c0/Python/thread_pthread.h#L486-L506 https://github.com/python/cpython/commit/187aa545165d (py3 fix) PyPy has the same bug for both pypy2 and pypy3: https://bitbucket.org/pypy/pypy/src/578667b3fef9/rpython/translator/c/src/thread_pthread.c#lines-443:465 https://bitbucket.org/pypy/pypy/src/5b42890d48c3/rpython/translator/c/src/thread_pthread.c#lines-443:465 Signalling condition outside of corresponding mutex is considered OK by POSIX, but in Python context it can lead to at least memory corruption if we consider the whole lifetime of python level lock. For example the following logical scenario: T1 T2 sema = Lock() sema.acquire() sema.release() sema.acquire() free(sema) ... can translate to the next C-level calls: T1 T2 # sema = Lock() sema = malloc(...) sema.locked = 0 pthread_mutex_init(&sema.mut) pthread_cond_init (&sema.lock_released) # sema.acquire() pthread_mutex_lock(&sema.mut) # sees sema.locked == 0 sema.locked = 1 pthread_mutex_unlock(&sema.mut) # sema.release() pthread_mutex_lock(&sema.mut) sema.locked = 0 pthread_mutex_unlock(&sema.mut) # OS scheduler gets in and relinquishes control from T2 # to another process ... # second sema.acquire() pthread_mutex_lock(&sema.mut) # sees sema.locked == 0 sema.locked = 1 pthread_mutex_unlock(&sema.mut) # free(sema) pthread_mutex_destroy(&sema.mut) pthread_cond_destroy (&sema.lock_released) free(sema) # ... e.g. malloc() which returns memory where sema was ... # OS scheduler returns control to T2 # sema.release() continues # # BUT sema was already freed and writing to anywhere # inside sema block CORRUPTS MEMORY. In particular if # _another_ python-level lock was allocated where sema # block was, writing into the memory can have effect on # further synchronization correctness and in particular # lead to deadlock on lock that was next allocated. pthread_cond_signal(&sema.lock_released) Note that T2.pthread_cond_signal(&sema.lock_released) CORRUPTS MEMORY as it is called when sema memory was already freed and is potentially reallocated for another object. The fix is to move pthread_cond_signal to be done under corresponding mutex: # sema.release() pthread_mutex_lock(&sema.mut) sema.locked = 0 pthread_cond_signal(&sema.lock_released) pthread_mutex_unlock(&sema.mut) To do so this patch cherry-picks thread_pthread.h part of the following 3.2 commit: commit 187aa545165d8d5eac222ecce29c8a77e0282dd4 Author: Kristján Valur Jónsson <kristjan@ccpgames.com> Date: Tue Jun 5 22:17:42 2012 +0000 Signal condition variables with the mutex held. Destroy condition variables before their mutexes. Python/ceval_gil.h | 9 +++++---- Python/thread_pthread.h | 15 +++++++++------ 2 files changed, 14 insertions(+), 10 deletions(-) (ceval_gil.h is Python3 specific and does not apply to Python2.7) The bug was there since 1994 - since at least [1]. It was discussed in 2001 with original code author[2], but the code was still considered to be race-free. In 2010 the place where pthread_cond_signal should be - before or after pthread_mutex_unlock - was discussed with the rationale to avoid threads bouncing[3,4,5], and in 2012 pthread_cond_signal was moved to be called from under mutex, but only for CPython3[6,7]. In 2019 the bug was (re-)discovered while testing Pygolang[8] on macOS with CPython2 and PyPy2 and PyPy3. [1] https://github.com/python/cpython/commit/2c8cb9f3d240 [2] https://bugs.python.org/issue433625 [3] https://bugs.python.org/issue8299#msg103224 [4] https://bugs.python.org/issue8410#msg103313 [5] https://bugs.python.org/issue8411#msg113301 [6] https://bugs.python.org/issue15038#msg163187 [7] https://github.com/python/cpython/commit/187aa545165d [8] https://pypi.org/project/pygolang (cherry picked from commit 187aa545165d8d5eac222ecce29c8a77e0282dd4) Co-Authored-By: Kristján Valur Jónsson <kristjan@ccpgames.com> 03 October 2019, 07:06:52 UTC
403ca7e [2.7] bpo-38338, test.pythoninfo: add more ssl infos (GH-16543) test.pythoninfo now logs environment variables used by OpenSSL and Python ssl modules, and logs attributes of 3 SSL contexts (SSLContext, default HTTPS context, stdlib context). (cherry picked from commit 1df1c2f8df53d005ff47af81aa02c58752b84e20) 02 October 2019, 16:36:32 UTC
8eb6415 [2.7] bpo-38243: Escape the server title of DocXMLRPCServer (GH-16447) Escape the server title of DocXMLRPCServer.DocXMLRPCServer when rendering the document page as HTML. 01 October 2019, 10:58:00 UTC
598f676 [2.7] bpo-38301: In Solaris family, we must be sure to use '-D_REENTRANT' (GH-16446). (#16454) (cherry picked from commit 52d1b86bde2b772a76919c76991c326384954bf1) Co-authored-by: Jesús Cea <jcea@jcea.es> 28 September 2019, 03:09:24 UTC
back to top