Add C++ overloads for _Py_CAST_impl() to handle 0/NULL. This will allow
C++ extensions that pass 0 or NULL to macros using _Py_CAST() to
continue to compile. Without this, you get an error like:
invalid ‘static_cast’ from type ‘int’ to type ‘_object*’
The modern way to use a NULL value in C++ is to use nullptr. However,
we want to not break extensions that do things the old way.
Co-authored-by: serge-sans-paille
When a `_PathParents` object has a drive or a root, the length of the
object is *one less* than than the length of `self._parts`, which resulted
in an off-by-one error when `path.parents[-n]` was fed through to
`self._parts[:-n - 1]`. In particular, `path.parents[-1]` was a malformed
path object with spooky properties.
This is addressed by adding `len(self)` to negative indices.
- Mark more ``umask()`` cases
- ``dup()`` is not supported
- ``/dev/null`` is not available
- document missing features
- mark more modules as not available
This is purely for SEO as this is the actual generic name for this kind of method and it currently does not appear in a Google search for "python constant time compare". Not creating an issue or setting this up for backports as its trivial (I think) and not a functional change.
* bpo-42272: improve message/module warning filter docs
"The Warnings Filter" section of the warnings module documentation
describes the message and module filters as "a string containing a
regular expression". While that is true when they are arguments to the
filterwarnings function, it is not true when they appear in -W or
$PYTHONWARNINGS where they are matched literally (after stripping any
starting/ending whitespace). Update the documentation to note when they
are matched literally. Also clarify that module matches the
"fully-qualified module name", rather than "module name" which is
ambiguous.
skip news (since this is a doc fix)
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* bpo-42272: remove bad submodule warning filter doc
The `error:::mymodule[.*]` example in the "Describing Warning Filters"
section of the warnings module documentation does not behave as the
comment describes. Since the module portion of the filter string is
interpreted literally, it would match a module with a fully-qualified
name that is literally `mymodule[.*]`.
Unfortunately, there is not a way to match '"module" and any subpackages
of "mymodule"' as documented, since the module part of a filter string
is matched literally. Instead, update the filter and comment to match
only "mymodule".
skip news (since this is a doc fix)
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* bpo-42272: add warning filter doc changes to NEWS
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
This was added for bpo-40514 (gh-84694) to test out a per-interpreter GIL. However, it has since proven unnecessary to keep the experiment in the repo. (It can be done as a branch in a fork like normal.) So here we are removing:
* the configure option
* the macro
* the code enabled by the macro
In previous versions of Python if an IntEnum member was combined with another integer type value using a bit-wise operation, the resulting value would still be the IntEnum type. This change restores that behavior.
