* feat!: drop support for Python 3.8
The minimum supported version is now Python 3.9. pybind11 v3.0 was the last
release that supports Python 3.8. The deprecation note said that support goes
away in 3.1.
Remove the code paths that this makes dead:
- the `_PyObject_Vectorcall` fallback in `cast.h`
- the `frame->f_code` and `frame->f_back` fallbacks in `pytypes.h`
- the `PyFrame_FastToLocals` path in `get_type_override`
- the conditional `Py_VISIT(Py_TYPE(self))` in `tp_traverse`
- `PYBIND11_PYCONFIG_SUPPORT_PY_VERSION_HEX`, the pre-PyConfig interpreter
init, and the `widen_chars` helpers in `embed.h`
Assisted-by: ClaudeCode:claude-opus-5
* ci(appveyor): use Python 3.9
The AppVeyor job set `PYTHON: 38`, which makes the path `C:\Python38`.
The image gives Python 3.9.13 as `C:\Python39`.
Assisted-by: ClaudeCode:claude-opus-5
* feat!: require MSVC 2019 or newer
Python 3.9 is the new minimum, so MSVC 2017 is no longer needed. Raise the
compile-time floor to _MSC_VER 1920 and remove the workarounds that only
applied below it: std::launder, fold expressions, weak_from_this, aligned
new/delete, the C4100 warning helper, and the func_handle syntax error.
AppVeyor now builds with Visual Studio 2019.
Assisted-by: ClaudeCode:claude-opus-5
* fix(appveyor): build against the Python that has the test packages
CMake 4 has no FindPythonLibs, so pybind11 uses FindPython. FindPython reads
the registry before PATH and selected `C:\Python314-x64`, but the test packages
go into the Python on PATH. Pass `Python_ROOT_DIR` to name the correct one.
Also set `CMAKE_ARCH`. It was never set, so the architecture came from the
generator. Visual Studio 2017 defaults to Win32, but Visual Studio 2019
defaults to x64, which made this x86 job build 64-bit code.
Assisted-by: ClaudeCode:claude-opus-5
* fix(appveyor): give the linker Python's libs directory
The build compiled but failed to link with LNK1104 on a bare `python39.lib`.
That name comes from the `#pragma comment(lib, ...)` in pyconfig.h, so the
linker needs the directory. CMake 4 has no FindPythonLibs, and FindPython does
not add it for this Debug x86 build. Put it on LIB instead.
The directory listing is temporary, to confirm the library is present.
Assisted-by: ClaudeCode:claude-opus-5
* fix(appveyor): link the release Python library in Debug
The image ships python39_d.lib next to python39.lib, so FindPython picks the
debug import library for a Debug build. pybind11 undefines _DEBUG around
Python.h, so pyconfig.h asks for python39.lib instead and the link failed with
LNK1104. Name the release library for the debug slot.
Setting LIB does not work, because MSBuild replaces it from the toolset, and it
would link both import libraries.
Assisted-by: ClaudeCode:claude-opus-5
* chore(appveyor): print link settings to debug LNK1104
Revert the two attempted fixes. Neither changed the failure: setting LIB does
not survive MSBuild, and naming the release library for Python_LIBRARY_DEBUG
had no effect.
Print the Python cache entries and the link settings of a generated project
file instead, to see what the linker really gets. Temporary.
Assisted-by: ClaudeCode:claude-opus-5
* fix(appveyor): take the release Python library in Debug
The generated project file linked C:\Python39\libs\python39_d.lib in the Debug
configuration, because the image ships debug binaries next to the release ones.
pybind11 undefines _DEBUG around Python.h, so pyconfig.h asks for python39.lib
in a #pragma comment(lib), which nothing on the link line satisfies and no
library directory holds. Map Debug to the release artifacts.
Assisted-by: ClaudeCode:claude-opus-5
* chore(appveyor): drop the temporary link diagnostic
Assisted-by: ClaudeCode:claude-opus-5
* fix(tests): guard the unraisable warning filter for pytest < 6
The distro pytest in the Clang and GCC Docker jobs has no
PytestUnraisableExceptionWarning, so an unconditional filterwarnings
mark makes pytest fail with an INTERNALERROR after the tests pass.
Assisted-by: ClaudeCode:claude-opus-5
Claude-Session: https://claude.ai/code/session_01Aimf6HuSz1vLRwBnbxmCTc
* docs: address review items on version hints, embed docs, and a PyPy xfail
Extend Python_ADDITIONAL_VERSIONS through 3.15, describe the PyConfig
behavior of initialize_interpreter, and drop the stale Python 3.8 wording
from the PyPy xfail reason.
Assisted-by: ClaudeCode:claude-opus-5
* Update README.rst
Co-authored-by: Ralf W. Grosse-Kunstleve <rwgkio@gmail.com>
---------
Co-authored-by: Ralf W. Grosse-Kunstleve <rwgkio@gmail.com>
* fix(cmake): do not use Python::Interpreter when cross-compiling
* chore: apply cmake-format to pybind11NewTools.cmake
* fix(cmake): do not look for Python Interpreter component when cross-compiling
* feat(cmake): guess Python extension suffix
* fix: add pybind11GuessPythonExtSuffix.cmake to packaging test
* Use PYBIND11_CROSSCOMPILING instead of CMAKE_CROSSCOMPILING
* refactor: require PYBIND11_USE_CROSSCOMPILING
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
---------
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
Co-authored-by: Henry Schreiner <henryschreineriii@gmail.com>
* cmake: split extension
Into suffix and debug postfix. Pybind11 is currently treating both as
suffix, which is problematic when something else defines the
DEBUG_POSTFIX because they will be concatenated.
pybind11_extension sets SUFFIX to _d.something and if DEBUG_POSTFIX is
set to _d.
_d + _d.something = _d_d.something
The issue has been reported at:
https://github.com/pybind/pybind11/issues/4699
* style: pre-commit fixes
* fix(cmake): support postfix for old FindPythonInterp mode too
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
---------
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Henry Schreiner <henryschreineriii@gmail.com>
* fix: PyPy needs to overrite broken FindPythonInterp values
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
* fix: add flag to opt-in to new (cross-compile) behavior
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
* Apply suggestions from code review
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
* Use sysconfig in Python >= 3.10
Rely on sysconfig for installation paths for Python >= 3.10. distutils
has been deprecated and will be removed.
Fixes: #3677
* Explicitly select the posix_prefix scheme for platinclude on Debian
Debian's default scheme is posix_local, for installing locally-built
packages to /usr/local/. We want to find the Python headers in /usr/,
so search posix_prefix.
* chore: drop Python 3.5 support
* chore: more fstrings with flynt's help
* ci: drop Python 3.5
* chore: bump dependency versions
* docs: touch up py::args
* tests: remove deprecation warning
* Ban smartquotes
* Very minor tweaks (by-product of reviewing PR #3719).
Co-authored-by: Aaron Gokaslan <skylion.aaron@gmail.com>
Co-authored-by: Ralf W. Grosse-Kunstleve <rwgk@google.com>
* `#error BYE_BYE_GOLDEN_SNAKE`
* Removing everything related to 2.7 from ci.yml
* Commenting-out Centos7
* Removing `PYTHON: 27` from .appveyor.yml
* "PY2" removal, mainly from tests. C++ code is not touched.
* Systematic removal of `u` prefix from `u"..."` and `u'...'` literals. Collateral cleanup of a couple minor other things.
* Cleaning up around case-insensitive hits for `[^a-z]py.*2` in tests/.
* Removing obsolete Python 2 mention in compiling.rst
* Proper `#error` for Python 2.
* Using PY_VERSION_HEX to guard `#error "PYTHON 2 IS NO LONGER SUPPORTED.`
* chore: bump pre-commit
* style: run pre-commit for pyupgrade 3+
* tests: use sys.version_info, not PY
* chore: more Python 2 removal
* Uncommenting Centos7 block (PR #3691 showed that it is working again).
* Update pre-commit hooks
* Fix pre-commit hook
* refactor: remove Python 2 from CMake
* refactor: remove Python 2 from setup code
* refactor: simplify, better static typing
* feat: fail with nice messages
* refactor: drop Python 2 C++ code
* docs: cleanup for Python 3
* revert: intree
revert: intree
* docs: minor touchup to py2 statement
Co-authored-by: Henry Schreiner <henryschreineriii@gmail.com>
Co-authored-by: Aaron Gokaslan <skylion.aaron@gmail.com>
* fix: match new extension discovery with changes to classic discovery
Followup to #2638 - this was fixed in 2.6.0, but only for classic Python
* fix: followup to avoid warnings
* Use LIBDIR and MULTIARCH on linux to find python library
* Remove apple-specific setting; the non-windows one should work fine on OS X
* Default LIBDIR/MULTIARCH to '' (to avoid getting None)
* Remove trailing whitespace from FindPythonLibsNew
Fixes#365. `sysconfig.get_config_var('SO')` already returns the correct
PYTHON_MODULE_EXTENSION, even for debug builds, so there is no need to
add anything else manually.
When run on windows in a venv, PYTHON_LIBRARY pointet to a non-existant
location in the virtual environment directory.
This has been fixed by testing if the path exists and, if not, trying
an alternative path, relative to the PYTHON_INCLUDE_DIR.
If the alternative path doesn't exit as well, an error will be raised.
