python / cpython

Explicitly cast PyHKEYObject* to PyObject* to call _PyObject_Init().

…-20312)

See PEP 623 for detail.

…han duplicating it in 'compile.c' (GH-21714)

Generate information about jumps from 'opcode.py' rather than duplicate it in 'compile.c'

…H-17536)

Co-authored-by: Jeffrey Kintscher <websurfer@surf2c.net>

On Windows, fix asyncio recv_into() return value when the socket/pipe
is closed (BrokenPipeError): return 0 rather than an empty byte
string (b'').

incr cannot be larger than INT_MAX: downcast to int explicitly.

…-21718)

regrtest_unraisable_hook() temporarily replaces sys.stderr with
sys.__stderr__ to help to display errors when a test captures stderr.

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).

Co-authored-by: Ankit Chandawala <achandaw@amazon.com>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>

…ions and ordering (#21574)

Also added PEP 585 deprecation notes.

)

…21517)

* Move 'peephole' optimizations into compile.c and perform them directly on the CFG.

Automerge-Triggered-By: @brettcannon

…-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.

…1665)

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

…H-21653)

Co-Authored-By: Baptiste Darthenay <baptiste.darthenay@gmail.com>

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.

Co-Authored-By: Rishi <rishi93dev@gmail.com>

Automerge-Triggered-By: @gvanrossum

Automerge-Triggered-By: @lysnikolaou

…ation (GH-19969)

(We censor the heck out of actions and some other stuff using a custom "highlighter".)

Co-authored-by: Guido van Rossum <guido@python.org>

The error is exposed on non-UTF-8 locales.