CAM Gerlach [Fri, 20 May 2022 21:47:51 +0000 (15:47 -0600)]
gh-92611: Clarify planned removal version in PEP 594-deprecated modules (GH-92793)
As discussed in #92611 and #92564 and as a followup to PR #92612 , this 3.11+ only PR uses the proper `deprecated-removed` role for the modules deprecated by PEP 593 (PEP-594) to clearly indicate to users that a removal version is planned and what it is, so they can prepare accordingly or voice any unanticipated impacts.
Related to #92792 ; if we decide to backport that PR, the upgrade to using `deprecated-removed` on those functions can be moved to this one.
Michael Osipov [Thu, 19 May 2022 15:42:21 +0000 (17:42 +0200)]
gh-78630: Drop invalid HP aCC compiler switch -fPIC on HP-UX (#8847)
At compile time, '+z' is already properly used with HP aCC, and shared
libraries are correctly linked with '+b'. The '-fPIC' switch can safely be
dropped.
Martin Fischer [Thu, 19 May 2022 15:34:58 +0000 (17:34 +0200)]
bpo-46879: Fix incorrect sphinx object names in doc (GH-31615)
API members documented in sphinx have an object name, which allow the
documentation to be linked from other projects. Sphinx calculates the
object name by prefixing the current module name to the directive
argument, e.g:
.. module:: foo
.. function:: bar.baz
becomes foo.bar.baz. Since these anchors aren't displayed in the
documentation, some mistakes have crept in, namely the Python stdlib
documentation currently contains the objects:
This commit fixes this by making use of the :module: option which
without an argument makes sphinx take the directive argument as is
for the object name (avoiding the prefixing of the current module
name that led to these broken object names).
Filipe Laíns [Mon, 16 May 2022 23:05:47 +0000 (00:05 +0100)]
gh-92265: set meta_path and path_hooks correctly in test_reload_namespace_changed (GH-92275)
Previously, we were blocking the frozen imports and forcing the source
version to be used, but we did not fix up sys.meta_path or
sys.path_hooks, causing the frozen importers to leak into the source
version of the test.
Serhiy Storchaka [Mon, 16 May 2022 05:25:29 +0000 (08:25 +0300)]
gh-92530: Fix an issue that occurred after interrupting threading.Condition.notify (GH-92534)
If Condition.notify() was interrupted just after it released the waiter lock,
but before removing it from the queue, the following calls of notify() failed
with RuntimeError: cannot release un-acquired lock.
Victor Stinner [Sun, 15 May 2022 09:19:52 +0000 (11:19 +0200)]
gh-92781: Avoid mixing declarations and code in C API (#92783)
Avoid mixing declarations and code in the C API to fix the compiler
warning: "ISO C90 forbids mixed declarations and code"
[-Werror=declaration-after-statement].
Victor Stinner [Fri, 13 May 2022 11:40:22 +0000 (13:40 +0200)]
gh-85858: Remove PyUnicode_InternImmortal() function (#92579)
Remove the PyUnicode_InternImmortal() function and the
SSTATE_INTERNED_IMMORTAL macro.
The PyUnicode_InternImmortal() function is still exported in the
stable ABI. The function is removed from the API.
PyASCIIObject.state.interned size is now a single bit, rather than 2
bits.
Keep SSTATE_NOT_INTERNED and SSTATE_INTERNED_MORTAL macros for
backward compatibility, but no longer use them internally since the
interned member is now a single bit and so can only have two values
(interned or not interned).
Victor Stinner [Fri, 13 May 2022 09:49:56 +0000 (11:49 +0200)]
gh-89653: PEP 670: Convert PyUnicode_KIND() macro to function (#92705)
In the limited C API version 3.12, PyUnicode_KIND() is now
implemented as a static inline function. Keep the macro for the
regular C API and for the limited C API version 3.11 and older to
prevent introducing new compiler warnings.
Update _decimal.c and stringlib/eq.h for PyUnicode_KIND().
The old behavior still raised an error in a similar way, but only
because subsequent calculations happened to fail as well. Better to fail
fast.
This also refactors the tests to split out the `fromtimestamp` and
`utcfromtimestamp` tests, and to get us closer to the actual desired
limits of the functions. As part of this, we also changed the way we
detect platforms where the same limits don't necessarily apply (e.g.
Windows).
As part of refactoring the tests to hit this condition explicitly (even
though the user-facing behvior doesn't change in any way we plan to
guarantee), I noticed that there was a difference in the places that
`datetime.utcfromtimestamp` fails in the C and pure Python versions, which
was fixed by skipping the "probe for fold" logic for UTC specifically —
since UTC doesn't have any folds or gaps, we were never going to find a
fold value anyway. This should prevent some failures in the pure python
`utcfromtimestamp` method on timestamps close to 0001-01-01.
There are two separate news entries for this because one is a
potentially user-facing change, the other is an internal code
correctness change that, if anything, changes some error messages. The
two happen to be coupled because of the test refactoring, but they are
probably best thought of as independent changes.
Victor Stinner [Wed, 11 May 2022 22:49:03 +0000 (00:49 +0200)]
gh-89653: PEP 670: Use PyObject* type for parameters (#92694)
Use the PyObject* type for parameters of static inline functions:
* Py_SIZE(): same parameter type than PyObject_Size()
* PyList_GET_SIZE(), PyList_SET_ITEM(): same parameter type than
PyList_Size() and PyList_SetItem()
* PyTuple_GET_SIZE(), PyTuple_SET_ITEM(): same parameter type than
PyTuple_Size() and PyTuple_SetItem().