Andy Lester [Fri, 28 Feb 2020 02:44:52 +0000 (20:44 -0600)]
closes bpo-39721: Fix constness of members of tok_state struct. (GH-18600)
The function PyTokenizer_FromUTF8 from Parser/tokenizer.c had a comment:
/* XXX: constify members. */
This patch addresses that.
In the tok_state struct:
* end and start were non-const but could be made const
* str and input were const but should have been non-const
Changes to support this include:
* decode_str() now returns a char * since it is allocated.
* PyTokenizer_FromString() and PyTokenizer_FromUTF8() each creates a
new char * for an allocate string instead of reusing the input
const char *.
* PyTokenizer_Get() and tok_get() now take const char ** arguments.
* Various local vars are const or non-const accordingly.
I was able to remove five casts that cast away constness.
Denis Chernikov [Fri, 21 Feb 2020 09:17:50 +0000 (12:17 +0300)]
Reuse identifier of PREDICT macros as PREDICT_ID (GH-17155)
In function `_PyEval_EvalFrameDefault`, macros PREDICT and PREDICTED use the same identifier creation scheme, which may be shared between them, reducing code repetition, and do ensure that the same identifier is generated.
Petr Viktorin [Tue, 18 Feb 2020 15:13:17 +0000 (16:13 +0100)]
bpo-37207: Use vectorcall for range() (GH-18464)
This continues the `range()` part of #13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.
Kyle Meyer [Tue, 18 Feb 2020 09:48:57 +0000 (04:48 -0500)]
bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337)
When `allow_abbrev` was first added, disabling the abbreviation of
long options broke the grouping of short flags ([bpo-26967](https://bugs.python.org/issue26967)). As a fix, b1e4d1b603 (contained in v3.8) ignores `allow_abbrev=False` for a
given argument string if the string does _not_ start with "--"
(i.e. it doesn't look like a long option).
This fix, however, doesn't take into account that long options can
start with alternative characters specified via `prefix_chars`,
introducing a regression: `allow_abbrev=False` has no effect on long
options that start with an alternative prefix character.
The most minimal fix would be to replace the "starts with --" check
with a "starts with two prefix_chars characters". But
`_get_option_tuples` already distinguishes between long and short
options, so let's instead piggyback off of that check by moving the
`allow_abbrev` condition into `_get_option_tuples`.
Thomas Moreau [Sun, 16 Feb 2020 18:09:26 +0000 (19:09 +0100)]
bpo-39104: Fix hanging ProcessPoolExecutor on shutdown nowait with pickling failure (GH-17670)
As reported initially by @rad-pat in #6084, the following script causes a deadlock.
```
from concurrent.futures import ProcessPoolExecutor
class ObjectWithPickleError():
"""Triggers a RuntimeError when sending job to the workers"""
def __reduce__(self):
raise RuntimeError()
if __name__ == "__main__":
e = ProcessPoolExecutor()
f = e.submit(id, ObjectWithPickleError())
e.shutdown(wait=False)
f.result() # Deadlock on get
```
This is caused by the fact that the main process is closing communication channels that might be necessary to the `queue_management_thread` later. To avoid this, this PR let the `queue_management_thread` manage all the closing.
bpo-39606: allow closing async generators that are already closed (GH-18475)
The fix for [bpo-39386](https://bugs.python.org/issue39386) attempted to make it so you couldn't reuse a
agen.aclose() coroutine object. It accidentally also prevented you
from calling aclose() at all on an async generator that was already
closed or exhausted. This commit fixes it so we're only blocking the
actually illegal cases, while allowing the legal cases.
The new tests failed before this patch. Also confirmed that this fixes
the test failures we were seeing in Trio with Python dev builds:
https://github.com/python-trio/trio/pull/1396
Add Include/cpython/bytearrayobject.h and
Include/cpython/bytesobject.h header files.
Move CPython C API from Include/bytesobject.h into a new
Include/cpython/bytesobject.h header file which is included by
Include/bytesobject.h. Do a similar change for
Include/bytearrayobject.h.
Victor Stinner [Wed, 12 Feb 2020 21:32:34 +0000 (22:32 +0100)]
bpo-35081: Move bytes_methods.h to the internal C API (GH-18492)
Move the bytes_methods.h header file to the internal C API as
pycore_bytes_methods.h: it only contains private symbols (prefixed by
"_Py"), except of the PyDoc_STRVAR_shared() macro.
William Chargin [Wed, 12 Feb 2020 19:56:02 +0000 (11:56 -0800)]
bpo-18819: tarfile: only set device fields for device files (GH-18080)
The GNU docs describe the `devmajor` and `devminor` fields of the tar
header struct only in the context of character and block special files,
suggesting that in other cases they are not populated. Typical utilities
behave accordingly; this patch teaches `tarfile` to do the same.
Victor Stinner [Wed, 12 Feb 2020 12:02:29 +0000 (13:02 +0100)]
bpo-21016: pydoc and trace use sysconfig (GH-18476)
bpo-21016, bpo-1294959: The pydoc and trace modules now use the
sysconfig module to get the path to the Python standard library, to
support uncommon installation path like /usr/lib64/python3.9/ on
Fedora.
Roger Hurwitz [Tue, 11 Feb 2020 06:56:02 +0000 (22:56 -0800)]
bpo-38374: Remove weakref.ReferenceError from docs (GH-18452)
Reflecting changes to the code, removed weakref.ReferenceError from weakref.rst and exceptions.rst.
Issue submitter provided evidence that the `weakref.ReferenceError` alias for `ReferenceError` was removed from the code in 2007. Working with @gvanrossum at PyCascades CPython sprint we looked at the code and confirmed that `weakref.ReferenceError` was no longer in `weakref.py`.
Based on that analysis I removed references `weakref.ReferenceError` from the two documents where it was still being referenced: `weakref.rst` and `exceptions.rst`.
Eric Wieser [Mon, 10 Feb 2020 23:32:18 +0000 (23:32 +0000)]
Correct the documented default encoding (GH-18429)
From the source for `PyUnicode_Decode`, the implementation is:
```
if (encoding == NULL) {
return PyUnicode_DecodeUTF8Stateful(s, size, errors, NULL);
}
```
which is pretty clearly not defaulting to ASCII.
---
I assume this needs neither a news entry nor bpo link.