`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.
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.
It was a no-op when used as recommended (after close()).
I had to debug one test (test__sock_sendfile_native_failure) --
the cleanup sequence for the test fixture was botched.
Hopefully that's not a portend of problems in user code --
this has never worked so people may well be doing this wrong. :-(
Co-authored-by: kumar aditya
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.
Newly supported interpreter definition syntax:
- `op(NAME, (input_stack_effects -- output_stack_effects)) { ... }`
- `macro(NAME) = OP1 + OP2;`
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`
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
* 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().
* 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)
* responding to comments
* missed this
* one more suggested edit
* wordsmithing
Replace "Py_XDECREF(var); var = NULL;" with "Py_CLEAR(var);".
Don't replace "Py_DECREF(var); var = NULL;" with "Py_CLEAR(var);". It
would add an useless "if (var)" test in code path where var cannot be
NULL.
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.
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.
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.
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>
Victor Stinner
Barney Gale
Stanley
Gary Donovan
Zackery Spytz
Erlend E. Aasland
colorfulappl
Kumar Aditya
Zachary Ware
Guido van Rossum
Irit Katriel
zhanpon
SQLPATCH
David Hewitt
Illia Volochii
Nikita Sobolev
Hugo van Kemenade
Steve Dower
Ronald Oussoren
ram vikram singh
Skip Montanaro
Charles Machalow
Serhiy Storchaka
Petr Viktorin
Dong Uk, Kang
mpage
Batuhan Taskaya
GabrielAnguita