GH-84559: Deprecate fork being the multiprocessing default. (#100618)
This starts the process. Users who don't specify their own start method
and use the default on platforms where it is 'fork' will see a
DeprecationWarning upon multiprocessing.Pool() construction or upon
multiprocessing.Process.start() or concurrent.futures.ProcessPool use.
See the related issue and documentation within this change for details.
John Belmonte [Wed, 1 Feb 2023 10:01:28 +0000 (19:01 +0900)]
datetime.rst: fix combine() signature (#101490)
The default `tzinfo` param of the `combine()` signature pseudocode was erroneously `self.tzinfo`.
`self` has no meaning in the context of a classmethod, and the datetime class itself has no `tzinfo` attribute. The correct default pseudocode is `time.tzinfo`, reflecting that the default is the `tzinfo` attribute of the `time` parameter.
Shantanu [Tue, 31 Jan 2023 05:39:30 +0000 (21:39 -0800)]
gh-77607: Improve accuracy of os.path.join docs (#101406)
This is a follow-up to #100811.
One of the changes in that PR isn't accurate in that
`os.path.join('', '')` will not end in a separator.
This reverts that change to the previous wording that used "only", but
explicitly calls out the case where the last part ends in a separator,
which is what caused confusin in #77607 and motivated the change
in #100811.
Eric Snow [Mon, 30 Jan 2023 19:07:48 +0000 (12:07 -0700)]
gh-59956: Clarify Runtime State Status Expectations (gh-101308)
A PyThreadState can be in one of many states in its lifecycle, represented by some status value. Those statuses haven't been particularly clear, so we're addressing that here. Specifically:
* made the distinct lifecycle statuses clear on PyThreadState
* identified expectations of how various lifecycle-related functions relate to status
* noted the various places where those expectations don't match the actual behavior
At some point we'll need to address the mismatches.
Gregory P. Smith [Sat, 28 Jan 2023 02:35:14 +0000 (18:35 -0800)]
gh-39615: Add warnings.warn() skip_file_prefixes support (#100840)
`warnings.warn()` gains the ability to skip stack frames based on code
filename prefix rather than only a numeric `stacklevel=` via a new
`skip_file_prefixes=` keyword argument.
Steve Dower [Fri, 27 Jan 2023 14:45:08 +0000 (14:45 +0000)]
gh-77532: Minor tweaks to allow compiling with PlatformToolset=ClangCL on Windows (GH-101352)
To use this, ensure that clang support was selected in Visual Studio Installer, then set the PlatformToolset environment variable to "ClangCL" and build as normal from the command line.
It remains unsupported, but at least is possible now for experimentation.
gh-99952: [ctypes] fix refcount issues in from_param() result. (#100169)
Fixes a reference counting issue with `ctypes.Structure` when a `from_param()` method call is used and the structure size is larger than a C pointer `sizeof(void*)`.
This problem existed for a very long time, but became more apparent in 3.8+ by change likely due to garbage collection cleanup timing changes.
Martin Boisvert [Tue, 24 Jan 2023 16:35:16 +0000 (11:35 -0500)]
gh-101135: Add backwards compatibility to Windows launcher for older 32-bit versions (GH-101138)
Python 2.x and up to 3.4 did not contain the "-32" in their registry name, so the 32 and 64-bit installs were treated equal. Since 3.5/PEP 514 this is no longer true, but we still want to detect the EOL versions correctly in case people are still using them.
Additionally, the code to replace a node with one with a lower sort key was buggy (wrong node chosen, replace never happened since parent was always NULL, replaced node never freed, etc)
Gregory P. Smith [Mon, 23 Jan 2023 23:03:26 +0000 (15:03 -0800)]
gh-100795: Don't call freeaddrinfo on failure. (#101252)
When getaddrinfo returns an error, the output pointer is in an unknown state
Don't call freeaddrinfo on it. See the issue for discussion and details with
links to reasoning. _Most_ libc getaddrinfo implementations never modify the
output pointer unless they are returning success.
Co-authored-by: Sergey G. Brester <github@sebres.de> Co-authored-by: Oleg Iarygin <dralife@yandex.ru>
Eric Snow [Mon, 23 Jan 2023 15:30:20 +0000 (08:30 -0700)]
gh-59956: Allow the "Trashcan" Mechanism to Work Without a Thread State (gh-101209)
We've factored out a struct from the two PyThreadState fields. This accomplishes two things:
* make it clear that the trashcan-related code doesn't need any other parts of PyThreadState
* allows us to use the trashcan mechanism even when there isn't a "current" thread state
Jacob Walls [Mon, 23 Jan 2023 01:16:48 +0000 (20:16 -0500)]
gh-83122: Deprecate testing element truth values in `ElementTree` (#31149)
When testing element truth values, emit a DeprecationWarning in all implementations.
This had emitted a FutureWarning in the rarely used python-only implementation since ~2.7 and has always been documented as a behavior not to rely on.
Matching an element in a tree search but having it test False can be unexpected. Raising the warning enables making the choice to finally raise an exception for this ambiguous behavior in the future.
Mark Dickinson [Sun, 22 Jan 2023 18:44:49 +0000 (18:44 +0000)]
gh-67790: Support float-style formatting for Fraction instances (#100161)
This PR adds support for float-style formatting for `Fraction` objects: it supports the `"e"`, `"E"`, `"f"`, `"F"`, `"g"`, `"G"` and `"%"` presentation types, and all the various bells and whistles of the formatting mini-language for those presentation types. The behaviour almost exactly matches that of `float`, but the implementation works with the exact `Fraction` value and does not do an intermediate conversion to `float`, and so avoids loss of precision or issues with numbers that are outside the dynamic range of the `float` type.
Note that the `"n"` presentation type is _not_ supported. That support could be added later if people have a need for it.
There's one corner-case where the behaviour differs from that of float: for the `float` type, if explicit alignment is specified with a fill character of `'0'` and alignment type `'='`, then thousands separators (if specified) are inserted into the padding string:
For `Fraction`, only the `'0'` flag has the above behaviour with respect to thousands separators: there's no special-casing of the particular `'0='` fill-character/alignment combination. Instead, we treat the fill character `'0'` just like any other:
The `Fraction` formatter is also stricter about combining these two things: it's not permitted to use both the `'0'` flag _and_ explicit alignment, on the basis that we should refuse the temptation to guess in the face of ambiguity. `float` is less picky:
```python
>>> format(3.14, '0<011,.2f')
'3.140000000'
>>> format(Fraction('3.14'), '0<011,.2f')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/mdickinson/Repositories/python/cpython/Lib/fractions.py", line 414, in __format__
raise ValueError(
ValueError: Invalid format specifier '0<011,.2f' for object of type 'Fraction'; can't use explicit alignment when zero-padding
```