Victor Stinner [Thu, 13 Aug 2020 20:11:50 +0000 (22:11 +0200)]
bpo-40204, doc: Fix syntax of C variables (GH-21846)
For example, fix the following Sphinx 3 errors:
Doc/c-api/buffer.rst:102: WARNING: Error in declarator or parameters
Invalid C declaration: Expected identifier in nested name. [error at 5]
void \*obj
-----^
Doc/c-api/arg.rst:130: WARNING: Unparseable C cross-reference: 'PyObject*'
Invalid C declaration: Expected end of definition. [error at 8]
PyObject*
--------^
The modified documentation is compatible with Sphinx 2 and Sphinx 3.
Victor Stinner [Thu, 13 Aug 2020 19:41:54 +0000 (21:41 +0200)]
bpo-40204: Add :noindex: in the documentation (GH-21859)
Add :noindex: to duplicated documentation to fix "duplicate object
description" errors.
For example, fix this Sphinx 3 issue:
Doc/library/configparser.rst:1146: WARNING: duplicate object
description of configparser.ConfigParser.optionxform, other instance
in library/configparser, use :noindex: for one of them
Victor Stinner [Thu, 13 Aug 2020 17:16:02 +0000 (19:16 +0200)]
bpo-40204: Fix duplicates in the documentation (GH-21857)
Fix two Sphinx 3 issues:
Doc/c-api/buffer.rst:304: WARNING: Duplicate C declaration, also defined in 'c-api/buffer'.
Declaration is 'PyBUF_ND'.
Doc/c-api/unicode.rst:1603: WARNING: Duplicate C declaration, also defined in 'c-api/unicode'.
Declaration is 'PyObject* PyUnicode_Translate(PyObject *str, PyObject *table, const char *errors)'.
Victor Stinner [Wed, 12 Aug 2020 19:49:22 +0000 (21:49 +0200)]
bpo-40204: Allow pre-Sphinx 3 syntax in the doc (GH-21844)
Enable Sphinx 3.2 "c_allow_pre_v3" option and disable the
c_warn_on_allowed_pre_v3 option to make the documentation compatible
with Sphinx 2 and Sphinx 3.
Terry Jan Reedy [Mon, 10 Aug 2020 13:43:56 +0000 (09:43 -0400)]
bpo-41514: Fix buggy IDLE test (GH-21808)
test_run method test_fatal_error failed when run twice, as with
python -m test -m test_fatal_error test_idle test_idle
because func.called was not reinitialized to 0.
This bug caused a failure on a refleak buildbot.
Jiajie Zhong [Sat, 8 Aug 2020 19:29:03 +0000 (03:29 +0800)]
Doc: Add output to example code in programming FAQ (GH-21346)
Add output hint to document, part faq/programming, section [How do I write a function with output parameters (call by reference)?](https://docs.python.org/3/faq/programming.html#how-do-i-write-a-function-with-output-parameters-call-by-reference).
This patch make the output hint just like prefix code block.
Benjamin Kane [Sat, 8 Aug 2020 02:57:03 +0000 (19:57 -0700)]
Doc: Add a link to tutorial page from `open()` doc (GH-21737)
Adds a link to the "Reading and Writing Files" page so users can
more easily discover how file handles are handled with the `with`
context manager vs without it.
A (very) slight speed improvement for iterating over bytes (#21705)
My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes. Looking at the source I
observed that arrayiter_next() calls `getitem(ao, it->index++)` wheras
striter_next() uses the idiom (paraphrased)
item = PyLong_FromLong(seq->ob_sval[it->it_index]);
if (item != NULL)
++it->it_next;
return item;
I'm not 100% sure but I think that the second version has fewer
opportunity for the CPU to overlap the `index++` operation with the
rest of the code (which in both cases involves a call). So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError). And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).
With this, a loop like
for _ in b: pass
is now slightly *faster* than the same thing over an equivalent array,
rather than slightly *slower* (in both cases a few percent).
closes bpo-38156: Always handle interrupts in PyOS_StdioReadline. (GH-21569)
This consolidates the handling of my_fgets return values, so that interrupts are always handled, even if they come after EOF.
I believe PyOS_StdioReadline is still buggy in that I/O errors will not result in a proper Python exception being set. However, that is a separate issue.
Steve Dower [Tue, 28 Jul 2020 15:35:46 +0000 (16:35 +0100)]
bpo-41412 and bpo-40948: Windows installer updates (GH-21656)
Prevent installation on Windows 8 and earlier.
Download UCRT on demand when required (non-updated Windows 8.1 only)
Add reference to py launcher to post-install message
Pablo Galindo [Mon, 27 Jul 2020 22:46:59 +0000 (23:46 +0100)]
Validate the AST produced by the parser in debug mode (GH-21643)
This will improve the debug experience if something fails in the produced AST. Previously, errors in the produced AST can be felt much later like in the garbage collector or the compiler, making debugging them much more difficult.
bpo-41314: fixed annotations __future__ version (GH-21616)
PEP 563 was updated to change the release where `from __future__ import annotations` becomes the default (and only) behavior from 4.0 to 3.10. Update `__future__.py` and its docs to reflect this.