From 80d0a85d969d305c7436dc54f8939d7b6f441b5f Mon Sep 17 00:00:00 2001 From: Joshua Swanson <22283299+joshuaswanson@users.noreply.github.com> Date: Fri, 3 Apr 2026 20:07:03 +0200 Subject: [PATCH 1/2] gh-126676: Expand argparse docs for type=bool with warning and alternatives (#146435) Co-authored-by: joshuaswanson Co-authored-by: Savannah Ostrowski --- Doc/library/argparse.rst | 10 +++++++++- .../2026-03-25-00-00-00.gh-issue-126676.052336.rst | 2 ++ 2 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 Misc/NEWS.d/next/Documentation/2026-03-25-00-00-00.gh-issue-126676.052336.rst diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst index 5a463ee9821d61..8ba11b7d12d552 100644 --- a/Doc/library/argparse.rst +++ b/Doc/library/argparse.rst @@ -1118,7 +1118,15 @@ User defined functions can be used as well: The :func:`bool` function is not recommended as a type converter. All it does is convert empty strings to ``False`` and non-empty strings to ``True``. -This is usually not what is desired. +This is usually not what is desired:: + + >>> parser = argparse.ArgumentParser() + >>> _ = parser.add_argument('--verbose', type=bool) + >>> parser.parse_args(['--verbose', 'False']) + Namespace(verbose=True) + +See :class:`BooleanOptionalAction` or ``action='store_true'`` for common +alternatives. In general, the ``type`` keyword is a convenience that should only be used for simple conversions that can only raise one of the three supported exceptions. diff --git a/Misc/NEWS.d/next/Documentation/2026-03-25-00-00-00.gh-issue-126676.052336.rst b/Misc/NEWS.d/next/Documentation/2026-03-25-00-00-00.gh-issue-126676.052336.rst new file mode 100644 index 00000000000000..d2e275fdf08385 --- /dev/null +++ b/Misc/NEWS.d/next/Documentation/2026-03-25-00-00-00.gh-issue-126676.052336.rst @@ -0,0 +1,2 @@ +Expand :mod:`argparse` documentation for ``type=bool`` with a demonstration +of the surprising behavior and pointers to common alternatives. From dea4083aa952c955a7c3a7657034bd38889a4e22 Mon Sep 17 00:00:00 2001 From: Chris Eibl <138194463+chris-eibl@users.noreply.github.com> Date: Fri, 3 Apr 2026 21:42:13 +0200 Subject: [PATCH 2/2] GH-146210: Fix building the jit stencils on Windows when the interpreter is built with a different clang version (#146338) Co-authored-by: Savannah Ostrowski --- .../2026-03-23-20-06-35.gh-issue-146210.C01Rmq.rst | 2 ++ Tools/jit/_llvm.py | 12 +++++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 Misc/NEWS.d/next/Build/2026-03-23-20-06-35.gh-issue-146210.C01Rmq.rst diff --git a/Misc/NEWS.d/next/Build/2026-03-23-20-06-35.gh-issue-146210.C01Rmq.rst b/Misc/NEWS.d/next/Build/2026-03-23-20-06-35.gh-issue-146210.C01Rmq.rst new file mode 100644 index 00000000000000..ce59a9a3a571b4 --- /dev/null +++ b/Misc/NEWS.d/next/Build/2026-03-23-20-06-35.gh-issue-146210.C01Rmq.rst @@ -0,0 +1,2 @@ +Fix building the jit stencils on Windows when the interpreter is built with +a different clang version. Patch by Chris Eibl. diff --git a/Tools/jit/_llvm.py b/Tools/jit/_llvm.py index 8b68c1e8636af7..a4aaacdf41249d 100644 --- a/Tools/jit/_llvm.py +++ b/Tools/jit/_llvm.py @@ -42,9 +42,19 @@ async def _run(tool: str, args: typing.Iterable[str], echo: bool = False) -> str async with _CORES: if echo: print(shlex.join(command)) + + if os.name == "nt": + # When building with /p:PlatformToolset=ClangCL, the VS build + # system puts that clang's include path into INCLUDE. The JIT's + # clang may be a different version, and mismatched headers cause + # build errors. See https://github.com/python/cpython/issues/146210. + env = os.environ.copy() + env.pop("INCLUDE", None) + else: + env = None try: process = await asyncio.create_subprocess_exec( - *command, stdout=subprocess.PIPE + *command, stdout=subprocess.PIPE, env=env ) except FileNotFoundError: return None