… sandbox (GH-32418)

_Py_closerange() currently assumes that close_range() closes
all file descriptors even if it returns an error (other than ENOSYS).
This assumption can be wrong on Linux if a seccomp sandbox denies
the underlying syscall, pretending that it returns EPERM or EACCES.
In this case _Py_closerange() won't close any descriptors at all,
which in the worst case can be a security issue.

Fix this by falling back to other methods in case of any close_range()
error. Note that fallbacks will not be triggered on any problems with
closing individual file descriptors because close_range() is documented
to ignore such errors on both Linux[1] and FreeBSD[2].

[1] https://man7.org/linux/man-pages/man2/close_range.2.html
[2] https://www.freebsd.org/cgi/man.cgi?query=close_range&sektion=2

…on (GH-32365)

Co-authored-by: Brandt Bucher <brandt@python.org>

Signed-off-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>

Co-authored-by: Brett Cannon <brett@python.org>

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

Since `title()` mentions its own short-comings, it should also mention the library function which does not possess them.

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

Co-authored-by: Éric <merwok@netwok.org>

Remove the Include/code.h header file. C extensions should only
include the main <Python.h> header file.

Python.h includes directly Include/cpython/code.h instead.

…-32364)

Move the private _PyComplex_FormatAdvancedWriter() function to the
internal C API. This function is no longer exported.

…shared sources (GH-32338)

Speed up test_peg_generator by using a static library for shared sources to avoid recompiling as much code.

…smtpd (GH-32350)

…quence.index (GH-32330)

Copying and pickling instances of subclasses of builtin types
bytearray, set, frozenset, collections.OrderedDict, collections.deque,
weakref.WeakSet, and datetime.tzinfo now copies and pickles instance attributes
implemented as slots.

…H-32333)

They were undocumented and never working.

People keep popping up reporting these as typos in the docs despite
being described as typos in the surrounding text.  Hopefully a comment
on the line itself makes it more obvious?

Arguably some of the typo examples are not using the "right" typo as the
"assret" one in particular is now detected by default due to how common
it was in actual code.  But I don't want to to typo chasing by changing
these examples to be other not yet auto-detected typos as they still
illustrate the point well enough.

…ABI (GH-32196)


Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@innova.no>