Victor Stinner [Tue, 29 Nov 2022 11:15:21 +0000 (12:15 +0100)]
gh-99845: Clean up _PyObject_VAR_SIZE() usage (#99847)
* code_sizeof() now uses an unsigned type (size_t) to compute the result.
* Fix _PyObject_ComputedDictPointer(): cast _PyObject_VAR_SIZE() to
Py_ssize_t, rather than long: it's a different type on 64-bit Windows.
* Clarify that _PyObject_VAR_SIZE() uses an unsigned type (size_t).
Victor Stinner [Tue, 29 Nov 2022 11:12:17 +0000 (12:12 +0100)]
gh-99845: Change _PyDict_KeysSize() return type to size_t (#99848)
* Change _PyDict_KeysSize() and shared_keys_usable_size() return type
from signed (Py_ssize_t) to unsigned (size_t) type.
* new_values() argument type is now unsigned (size_t).
* init_inline_values() now uses size_t rather than int for the 'i'
iterator variable.
* type.__sizeof__() implementation now uses unsigned (size_t) type.
* PyCode_GetNumFree() casts PyCode_GetNumFree.co_nfreevars from int
to Py_ssize_t to be future proof, and because Py_ssize_t is
commonly used in the C API.
* PyCode_GetNumFree() doesn't cast its argument: the replaced macro
already required the exact type PyCodeObject*.
* Add assertions in some functions using "CAST" macros to check
the arguments type when Python is built with assertions
(debug build).
* Remove an outdated comment in unicodeobject.h.
These slots are marked "should be treated as read-only" in the
table at the start of the document. That doesn't say anything about
setting them in the static struct.
`tp_bases` docs did say that it should be ``NULL`` (TIL!). If you
ignore that, seemingly nothing bad happens. However, some slots
may not be inherited, depending on which sub-slot structs are present.
(FWIW, NumPy sets tp_bases and is affected by the quirk -- though to
be fair, its DUAL_INHERIT code probably predates tp_bases docs, and
also the result happens to be benign.)
This patch makes things explicit.
It also makes the summary table legend easier to scan.
Ronald Oussoren [Sun, 27 Nov 2022 10:56:14 +0000 (11:56 +0100)]
GH-87235: Make sure "python /dev/fd/9 9</path/to/script.py" works on macOS (#99768)
On macOS all file descriptors for a particular file in /dev/fd
share the same file offset, that is ``open("/dev/fd/9", "r")`` behaves
more like ``dup(9)`` than a regular open.
This causes problems when a user tries to run "/dev/fd/9" as a script
because zipimport changes the file offset to try to read a zipfile
directory. Therefore change zipimport to reset the file offset after
trying to read the zipfile directory.
Brad Wolfe [Sun, 27 Nov 2022 10:25:12 +0000 (11:25 +0100)]
gh-85988: Change documentation for sys.float_info.rounds (GH-99675)
* Change documentation for sys.float_info.rounds
Change the documentation for sys.float_info.rounds to remove
references to C99 section 5.2.4.2.2 and instead place the
available values inline.
* Correction to previous documentation change
Newlines were not preserved in generated HTML on previous
commit. I have changes the list to a comma-separated list
of values and their meanings.
* Clarify source for value of FLT_ROUNDS
Clarify the source of the FLT_ROUNDS value and
change 'floating-point addition' to 'floating-point
arithmetic' to indicate that the rounding mode
applies to all arithmetic operations.
Nikita Sobolev [Sat, 26 Nov 2022 09:33:48 +0000 (12:33 +0300)]
gh-99502: mention bytes-like objects as input in `secrets.compare_digest` (GH-99512)
Now it is in sync with https://docs.python.org/3/library/hmac.html#hmac.compare_digest
It is the same function, just re-exported. So, I guess they should mention the same input types.
Terry Jan Reedy [Sat, 26 Nov 2022 00:03:16 +0000 (19:03 -0500)]
Fix typo in `__match_args__` doc (#99785)
A opy of #98549, whose author (@icecream17) uses a school computer that blocks the CLA site. I did not mention this in commit comment above so CLA bot does not pick up the name and request the CLA again.
Barney Gale [Fri, 25 Nov 2022 19:15:57 +0000 (19:15 +0000)]
gh-99029: Fix handling of `PureWindowsPath('C:\<blah>').relative_to('C:')` (GH-99031)
`relative_to()` now treats naked drive paths as relative. This brings its
behaviour in line with other parts of pathlib, and with `ntpath.relpath()`,
and so allows us to factor out the pathlib-specific implementation.
Kumar Aditya [Thu, 24 Nov 2022 16:06:06 +0000 (21:36 +0530)]
GH-66285: skip asyncio fork tests for platforms without md5 hash (#99745)
Such buildbots (at the time of writing, only "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash 3.x") cannot use multiprocessing with a fork server, so just skip the test there.
Ronald Oussoren [Wed, 23 Nov 2022 10:52:12 +0000 (11:52 +0100)]
GH-95283: Add note about compilers in Mac/README.txt (#99506)
The build machinery assumes that the compiler that's used
to build on macOS includes an SDK that's at least as new
as the OS version on the build machine. Explicitly mention
this in Mac/README.txt.
Also some other random improvements:
- Convert `WITH_EXCEPT_START` to use stack effects
- Fix lexer to balk at unrecognized characters, e.g. `@`
- Fix moved output names; support object pointers in cache
- Introduce `error()` method to print errors
- Introduce read_uint16(p) as equivalent to `*p`
Victor Stinner [Tue, 22 Nov 2022 21:17:06 +0000 (22:17 +0100)]
gh-99300: Replace Py_INCREF() with Py_NewRef() in _elementtree.c (#99696)
* Replace Py_INCREF() and Py_XINCREF() using a cast with Py_NewRef()
and Py_XNewRef() in Modules/_elementtree.c.
* Make reference counting more explicit: don't steal implicitly a
reference on PyList_SET_ITEM(), use Py_NewRef() instead.
* Replace PyModule_AddObject() with PyModule_AddObjectRef().
Skip Montanaro [Tue, 22 Nov 2022 18:06:36 +0000 (12:06 -0600)]
gh-99146 struct module documentation should have more predictable examples/warnings (GH-99141)
* nail down a couple examples to have more predictable output
* update a number of things, but this is really just a stash...
* added an applications section to describe typical uses for native and machine-independent formats
* make sure all format strings use a format prefix character
* responding to comments from @gpshead. Not likely finished yet.
* This got more involved than I expected...
* respond to several PR comments
* a lot of wordsmithing
* try and be more consistent in use of ``x`` vs ``'x'``
* expand examples a bit
* update the "see also" to be more up-to-date
* original examples relied on import * so present all examples as if
* reformat based on @gpshead comment (missed before)
Victor Stinner [Tue, 22 Nov 2022 13:22:22 +0000 (14:22 +0100)]
gh-99537: Use Py_SETREF() function in C code (#99656)
Fix potential race condition in code patterns:
* Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);"
* Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);"
* Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);"
Other changes:
* Replace "old = var; var = new; Py_DECREF(var)"
with "Py_SETREF(var, new);"
* Replace "old = var; var = new; Py_XDECREF(var)"
with "Py_XSETREF(var, new);"
* And remove the "old" variable.
Victor Stinner [Tue, 22 Nov 2022 12:39:11 +0000 (13:39 +0100)]
gh-99537: Use Py_SETREF() function in C code (#99657)
Fix potential race condition in code patterns:
* Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);"
* Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);"
* Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);"
Other changes:
* Replace "old = var; var = new; Py_DECREF(var)"
with "Py_SETREF(var, new);"
* Replace "old = var; var = new; Py_XDECREF(var)"
with "Py_XSETREF(var, new);"
* And remove the "old" variable.
Ronald Oussoren [Tue, 22 Nov 2022 10:33:37 +0000 (11:33 +0100)]
GH-92892: Add section about variadic functions to ctypes documentation (#99529)
On some platforms, and in particular macOS/arm64, the calling
convention for variadic arguments is different from the regular
calling convention. Add a section to the documentation to document
this.
Petr Viktorin [Tue, 22 Nov 2022 07:25:43 +0000 (08:25 +0100)]
gh-47146: Soft-deprecate structmember.h, expose its contents via Python.h (GH-99014)
The ``structmember.h`` header is deprecated, though it continues to be available
and there are no plans to remove it. There are no deprecation warnings. Old code
can stay unchanged (unless the extra include and non-namespaced macros bother
you greatly). Specifically, no uses in CPython are updated -- that would just be
unnecessary churn.
The ``structmember.h`` header is deprecated, though it continues to be
available and there are no plans to remove it.
Its contents are now available just by including ``Python.h``,
with a ``Py`` prefix added if it was missing:
- `PyMemberDef`, `PyMember_GetOne` and`PyMember_SetOne`
- Type macros like `Py_T_INT`, `Py_T_DOUBLE`, etc.
(previously ``T_INT``, ``T_DOUBLE``, etc.)
- The flags `Py_READONLY` (previously ``READONLY``) and
`Py_AUDIT_READ` (previously all uppercase)
Several items are not exposed from ``Python.h``:
- `T_OBJECT` (use `Py_T_OBJECT_EX`)
- `T_NONE` (previously undocumented, and pretty quirky)
- The macro ``WRITE_RESTRICTED`` which does nothing.
- The macros ``RESTRICTED`` and ``READ_RESTRICTED``, equivalents of
`Py_AUDIT_READ`.
- In some configurations, ``<stddef.h>`` is not included from ``Python.h``.
It should be included manually when using ``offsetof()``.
The deprecated header continues to provide its original
contents under the original names.
Your old code can stay unchanged, unless the extra include and non-namespaced
macros bother you greatly.
There is discussion on the issue to rename `T_PYSSIZET` to `PY_T_SSIZE` or
similar. I chose not to do that -- users will probably copy/paste that with any
spelling, and not renaming it makes migration docs simpler.
Co-Authored-By: Alexander Belopolsky <abalkin@users.noreply.github.com> Co-Authored-By: Matthias Braun <MatzeB@users.noreply.github.com>
Łukasz Langa [Mon, 21 Nov 2022 20:44:17 +0000 (21:44 +0100)]
gh-99659: Use correct exceptions in sqlite3 bigmem tests (#99660)
The tests in question were added in 0eec6276fdcd by Serhiy. Apparently,
sqlite3 changed exceptions raised in those cases in the mean time but
the tests never ran because they require a high `-M` setting in the
test runner.
Ronald Oussoren [Mon, 21 Nov 2022 09:50:20 +0000 (10:50 +0100)]
gh-99337: Fix compile errors with gcc 12 on macOS (#99470)
Fix a number of compile errors with GCC-12 on macOS:
1. In pylifecycle.c the compile rejects _Pragma within a declaration
2. posixmodule.c was missing a number of ..._RUNTIME macros for non-clang on macOS
3. _ctypes assumed that __builtin_available is always present on macOS