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.
bpo-41182 selector: use DefaultSelector based upon implementation (GH-21257)
On some platform such as VMware ESXi, DefaultSelector fails
to detect selector due to default value.
This fix adds a check and uses the correct selector depending upon
select implementation and actual call.
bpo-41295: Reimplement the Carlo Verre "hackcheck" (GH-21528)
Walk down the MRO backwards to find the type that originally defined the final `tp_setattro`, then make sure we are not jumping over intermediate C-level bases with the Python-level call.
bpo-41195: Add getter for Openssl security level (GH-21282)
Add an accessor under SSLContext.security_level as a wrapper around
SSL_CTX_get_security_level, see:
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_security_level.html
------
This is my first time contributing, so please pull me up on all the things I missed or did incorrectly.
Fix possibly-unitialized warning in string_parser.c. (GH-21503)
GCC says
```
../cpython/Parser/string_parser.c: In function ‘fstring_find_expr’:
../cpython/Parser/string_parser.c:404:93: warning: ‘cols’ may be used uninitialized in this function [-Wmaybe-uninitialized]
404 | p2->starting_col_offset = p->tok->first_lineno == p->tok->lineno ? t->col_offset + cols : cols;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
../cpython/Parser/string_parser.c:384:16: note: ‘cols’ was declared here
384 | int lines, cols;
| ^~~~
../cpython/Parser/string_parser.c:403:45: warning: ‘lines’ may be used uninitialized in this function [-Wmaybe-uninitialized]
403 | p2->starting_lineno = t->lineno + lines - 1;
| ~~~~~~~~~~~~~~~~~~^~~
../cpython/Parser/string_parser.c:384:9: note: ‘lines’ was declared here
384 | int lines, cols;
| ^~~~~
```
and, indeed, if `PyBytes_AsString` somehow fails, lines & cols will not be initialized.
Felix Yan [Wed, 15 Jul 2020 12:14:11 +0000 (20:14 +0800)]
bpo-41302: Fix build with system libmpdec (GH-21481)
Move definition of UNUSED from modified headers of libmpdec to
_decimal.c itself. This makes the vendored source closer to the
standalone library and fixes build with --with-system-libmpdec.
Tested to build fine with either system libmpdec or the vendored one.
bpo-32528: Document the change in inheritance of asyncio.CancelledError (GH-21474)
#msg373510
[bpo-32528]()/#13528 changed `asyncio.CancelledError` such that it no longer inherits from `concurrent.futures.CancelledError`. As this affects existing code, specifically when catching the latter instead of the former in exception handling, it should be documented in the "What's new in 3.8?" document.
Terry Jan Reedy [Thu, 9 Jul 2020 22:08:33 +0000 (18:08 -0400)]
bpo-37765: Add keywords to IDLE tab completions (GH-15138)
Keywords are present in the main module tab completion lists generated by rlcompleter, which is used by REPLs on *nix. Add all keywords to IDLE's main module name list except those already added from builtins (True, False, and None) . This list may also be used by Show Completions on the Edit menu, and its hot key.