[ { "path": ".appveyor.yml", "content": "version: 1.0.{build}\nimage:\n- Visual Studio 2017\ntest: off\nskip_branch_with_pr: true\nbuild:\n parallel: true\nplatform:\n- x86\nenvironment:\n matrix:\n - PYTHON: 38\n CONFIG: Debug\ninstall:\n- ps: |\n $env:CMAKE_GENERATOR = \"Visual Studio 15 2017\"\n if ($env:PLATFORM -eq \"x64\") { $env:PYTHON = \"$env:PYTHON-x64\" }\n $env:PATH = \"C:\\Python$env:PYTHON\\;C:\\Python$env:PYTHON\\Scripts\\;$env:PATH\"\n python -W ignore -m pip install --upgrade pip wheel\n python -W ignore -m pip install pytest numpy --no-warn-script-location pytest-timeout\n- ps: |\n Start-FileDownload 'https://gitlab.com/libeigen/eigen/-/archive/3.3.7/eigen-3.3.7.zip'\n 7z x eigen-3.3.7.zip -y > $null\n $env:CMAKE_INCLUDE_PATH = \"eigen-3.3.7;$env:CMAKE_INCLUDE_PATH\"\nbuild_script:\n- cmake -G \"%CMAKE_GENERATOR%\" -A \"%CMAKE_ARCH%\"\n -DCMAKE_CXX_STANDARD=14\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DCMAKE_SUPPRESS_REGENERATION=1\n .\n- set MSBuildLogger=\"C:\\Program Files\\AppVeyor\\BuildAgent\\Appveyor.MSBuildLogger.dll\"\n- cmake --build . --config %CONFIG% --target pytest -- /m /v:m /logger:%MSBuildLogger%\n- cmake --build . --config %CONFIG% --target cpptest -- /m /v:m /logger:%MSBuildLogger%\non_failure: if exist \"tests\\test_cmake_build\" type tests\\test_cmake_build\\*.log*\n" }, { "path": ".clang-format", "content": "---\n# See all possible options and defaults with:\n# clang-format --style=llvm --dump-config\nBasedOnStyle: LLVM\nAccessModifierOffset: -4\nAllowShortLambdasOnASingleLine: true\nAlwaysBreakTemplateDeclarations: Yes\nBinPackArguments: false\nBinPackParameters: false\nBreakBeforeBinaryOperators: All\nBreakConstructorInitializers: BeforeColon\nColumnLimit: 99\nCommentPragmas: 'NOLINT:.*|^ IWYU pragma:'\nIncludeBlocks: Regroup\nIndentCaseLabels: true\nIndentPPDirectives: AfterHash\nIndentWidth: 4\nLanguage: Cpp\nSpaceAfterCStyleCast: true\nStandard: Cpp11\nStatementMacros: ['PyObject_HEAD']\nTabWidth: 4\nIncludeCategories:\n - Regex: ''\n Priority: 4\n - Regex: '.*'\n Priority: 5\n...\n" }, { "path": ".clang-tidy", "content": "FormatStyle: file\n\nChecks: |\n *bugprone*,\n *performance*,\n clang-analyzer-optin.cplusplus.VirtualCall,\n clang-analyzer-optin.performance.Padding,\n cppcoreguidelines-init-variables,\n cppcoreguidelines-prefer-member-initializer,\n cppcoreguidelines-pro-type-static-cast-downcast,\n cppcoreguidelines-slicing,\n google-explicit-constructor,\n llvm-namespace-comment,\n misc-definitions-in-headers,\n misc-misplaced-const,\n misc-non-copyable-objects,\n misc-static-assert,\n misc-throw-by-value-catch-by-reference,\n misc-uniqueptr-reset-release,\n misc-unused-parameters,\n modernize-avoid-bind,\n modernize-loop-convert,\n modernize-make-shared,\n modernize-redundant-void-arg,\n modernize-replace-auto-ptr,\n modernize-replace-disallow-copy-and-assign-macro,\n modernize-replace-random-shuffle,\n modernize-shrink-to-fit,\n modernize-use-auto,\n modernize-use-bool-literals,\n modernize-use-default-member-init,\n modernize-use-emplace,\n modernize-use-equals-default,\n modernize-use-equals-delete,\n modernize-use-noexcept,\n modernize-use-nullptr,\n modernize-use-override,\n modernize-use-using,\n readability-avoid-const-params-in-decls,\n readability-braces-around-statements,\n readability-const-return-type,\n readability-container-size-empty,\n readability-delete-null-pointer,\n readability-else-after-return,\n readability-implicit-bool-conversion,\n readability-inconsistent-declaration-parameter-name,\n readability-make-member-function-const,\n readability-misplaced-array-index,\n readability-non-const-parameter,\n readability-qualified-auto,\n readability-redundant-casting,\n readability-redundant-function-ptr-dereference,\n readability-redundant-inline-specifier,\n readability-redundant-member-init,\n readability-redundant-smartptr-get,\n readability-redundant-string-cstr,\n readability-simplify-subscript-expr,\n readability-static-accessed-through-instance,\n readability-static-definition-in-anonymous-namespace,\n readability-string-compare,\n readability-suspicious-call-argument,\n readability-uniqueptr-delete-release,\n -bugprone-chained-comparison,\n -bugprone-easily-swappable-parameters,\n -bugprone-exception-escape,\n -bugprone-reserved-identifier,\n -bugprone-unused-raii,\n -performance-enum-size,\n -performance-inefficient-string-concatenation,\n\nCheckOptions:\n- key: modernize-use-equals-default.IgnoreMacros\n value: false\n- key: performance-for-range-copy.WarnOnAllAutoCopies\n value: true\n- key: performance-inefficient-string-concatenation.StrictMode\n value: true\n- key: performance-unnecessary-value-param.AllowedTypes\n value: 'exception_ptr$;'\n- key: readability-implicit-bool-conversion.AllowPointerConditions\n value: true\n\nHeaderFilterRegex: 'pybind11/.*h'\n" }, { "path": ".cmake-format.yaml", "content": "parse:\n additional_commands:\n pybind11_add_module:\n flags:\n - THIN_LTO\n - MODULE\n - SHARED\n - NO_EXTRAS\n - EXCLUDE_FROM_ALL\n - SYSTEM\n\nformat:\n line_width: 99\n tab_size: 2\n\n # If an argument group contains more than this many sub-groups\n # (parg or kwarg groups) then force it to a vertical layout.\n max_subgroups_hwrap: 2\n\n # If a positional argument group contains more than this many\n # arguments, then force it to a vertical layout.\n max_pargs_hwrap: 6\n\n # If a cmdline positional group consumes more than this many\n # lines without nesting, then invalidate the layout (and nest)\n max_rows_cmdline: 2\n separate_ctrl_name_with_space: false\n separate_fn_name_with_space: false\n dangle_parens: false\n\n # If the trailing parenthesis must be 'dangled' on its on\n # 'line, then align it to this reference: `prefix`: the start'\n # 'of the statement, `prefix-indent`: the start of the'\n # 'statement, plus one indentation level, `child`: align to'\n # the column of the arguments\n dangle_align: prefix\n # If the statement spelling length (including space and\n # parenthesis) is smaller than this amount, then force reject\n # nested layouts.\n min_prefix_chars: 4\n\n # If the statement spelling length (including space and\n # parenthesis) is larger than the tab width by more than this\n # amount, then force reject un-nested layouts.\n max_prefix_chars: 10\n\n # If a candidate layout is wrapped horizontally but it exceeds\n # this many lines, then reject the layout.\n max_lines_hwrap: 2\n\n line_ending: unix\n\n # Format command names consistently as 'lower' or 'upper' case\n command_case: canonical\n\n # Format keywords consistently as 'lower' or 'upper' case\n # unchanged is valid too\n keyword_case: 'upper'\n\n # A list of command names which should always be wrapped\n always_wrap: []\n\n # If true, the argument lists which are known to be sortable\n # will be sorted lexicographically\n enable_sort: true\n\n # If true, the parsers may infer whether or not an argument\n # list is sortable (without annotation).\n autosort: false\n\n# Causes a few issues - can be solved later, possibly.\nmarkup:\n enable_markup: false\n" }, { "path": ".codespell-ignore-lines", "content": "template \n template \n auto &this_ = static_cast(*this);\n if (load_impl(temp, false)) {\n return load_impl(src, false);\n ssize_t nd = 0;\n auto trivial = broadcast(buffers, nd, shape);\n auto ndim = (size_t) nd;\n int nd;\n ssize_t ndim() const { return detail::array_proxy(m_ptr)->nd; }\n using op = op_impl;\ntemplate \n template \n class_ &def(const detail::op_ &op, const Extra &...extra) {\n class_ &def_cast(const detail::op_ &op, const Extra &...extra) {\n int valu;\n explicit movable_int(int v) : valu{v} {}\n movable_int(movable_int &&other) noexcept : valu(other.valu) { other.valu = 91; }\n explicit indestructible_int(int v) : valu{v} {}\n REQUIRE(hld.as_raw_ptr_unowned()->valu == 19);\n REQUIRE(othr.valu == 19);\n REQUIRE(orig.valu == 91);\n (m.pass_valu, \"Valu\", \"pass_valu:Valu(_MvCtor)*_CpCtor\"),\natyp_valu rtrn_valu() { atyp_valu obj{\"Valu\"}; return obj; }\n assert m.atyp_valu().get_mtxt() == \"Valu\"\n// valu(e), ref(erence), ptr or p (pointer), r = rvalue, m = mutable, c = const,\n@pytest.mark.parametrize(\"access\", [\"ro\", \"rw\", \"static_ro\", \"static_rw\"])\nstruct IntStruct {\n explicit IntStruct(int v) : value(v){};\n ~IntStruct() { value = -value; }\n IntStruct(const IntStruct &) = default;\n IntStruct &operator=(const IntStruct &) = default;\n py::class_(m, \"IntStruct\").def(py::init([](const int i) { return IntStruct(i); }));\n py::implicitly_convertible();\n m.def(\"test\", [](int expected, const IntStruct &in) {\n [](int expected, const IntStruct &in) {\n" }, { "path": ".gitattributes", "content": "docs/*.svg binary\n" }, { "path": ".github/CODEOWNERS", "content": "*.cmake @henryiii\nCMakeLists.txt @henryiii\n*.yml @henryiii\n*.yaml @henryiii\n/tools/ @henryiii\n/pybind11/ @henryiii\nnoxfile.py @henryiii\n.clang-format @henryiii\n.clang-tidy @henryiii\n" }, { "path": ".github/CONTRIBUTING.md", "content": "Thank you for your interest in this project! Please refer to the following\nsections on how to contribute code and bug reports.\n\n### Reporting bugs\n\nBefore submitting a question or bug report, please take a moment of your time\nand ensure that your issue isn't already discussed in the project documentation\nprovided at [pybind11.readthedocs.org][] or in the [issue tracker][]. You can\nalso check [gitter][] to see if it came up before.\n\nAssuming that you have identified a previously unknown problem or an important\nquestion, it's essential that you submit a self-contained and minimal piece of\ncode that reproduces the problem. In other words: no external dependencies,\nisolate the function(s) that cause breakage, submit matched and complete C++\nand Python snippets that can be easily compiled and run in isolation; or\nideally make a small PR with a failing test case that can be used as a starting\npoint.\n\n## Pull requests\n\nContributions are submitted, reviewed, and accepted using GitHub pull requests.\nPlease refer to [this article][using pull requests] for details and adhere to\nthe following rules to make the process as smooth as possible:\n\n* Make a new branch for every feature you're working on.\n* Make small and clean pull requests that are easy to review but make sure they\n do add value by themselves.\n* Add tests for any new functionality and run the test suite (`cmake --workflow\n venv`) to ensure that no existing features break.\n* Please run [`pre-commit`][pre-commit] to check your code matches the\n project style. (Note that `gawk` is required.) Use `pre-commit run\n --all-files` before committing (or use installed-mode, check pre-commit docs)\n to verify your code passes before pushing to save time.\n* This project has a strong focus on providing general solutions using a\n minimal amount of code, thus small pull requests are greatly preferred.\n\n### Licensing of contributions\n\npybind11 is provided under a BSD-style license that can be found in the\n``LICENSE`` file. By using, distributing, or contributing to this project, you\nagree to the terms and conditions of this license.\n\nYou are under no obligation whatsoever to provide any bug fixes, patches, or\nupgrades to the features, functionality or performance of the source code\n(\"Enhancements\") to anyone; however, if you choose to make your Enhancements\navailable either publicly, or directly to the author of this software, without\nimposing a separate written license agreement for such Enhancements, then you\nhereby grant the following license: a non-exclusive, royalty-free perpetual\nlicense to install, use, modify, prepare derivative works, incorporate into\nother computer software, distribute, and sublicense such enhancements or\nderivative works thereof, in binary and source code form.\n\n\n## Development of pybind11\n\n### Quick setup\n\nTo setup a quick development environment, use [`nox`](https://nox.thea.codes).\nThis will allow you to do some common tasks with minimal setup effort, but will\ntake more time to run and be less flexible than a full development environment.\nIf you use [`pipx run nox`](https://pipx.pypa.io), you don't even need to\ninstall `nox`. Examples:\n\n```bash\n# List all available sessions\nnox -l\n\n# Run linters\nnox -s lint\n\n# Run tests on Python 3.9\nnox -s tests-3.9\n\n# Build and preview docs\nnox -s docs -- serve\n\n# Build SDists and wheels\nnox -s build\n```\n\n### Full setup\n\nTo setup an ideal development environment, run the following commands on a\nsystem with CMake 3.15+:\n\n```bash\npython3 -m venv .venv\nsource .venv/bin/activate\npip install -r tests/requirements.txt\ncmake -S . -B build -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON\ncmake --build build -j4\n```\n\nTips:\n\n* You can use `virtualenv` (faster, from PyPI) instead of `venv`.\n* You can select any name for your environment folder; if it contains \"env\" it\n will be ignored by git.\n* If you don't have CMake 3.15+, just add \"cmake\" to the pip install command.\n* You can use `-DPYBIND11_FINDPYTHON=ON` to use FindPython.\n* For a specific Python, you can use `-DPython_ROOT_DIR=/path/to` or\n `-DPython_EXECUTABLE=/path/to/python`.\n\n## CMake presets\n\nWe also support CMake presets. If you have [uv](https://docs.astral.sh/uv/),\nyou can use:\n\n```bash\ncmake --workflow venv\n```\n\nto setup a venv and run all tests. You can break this up into components\nif you want to use a specific version of Python (or any other config option) or\nbuild only one of the valid targets (listed below).\n\n```bash\ncmake --preset venv -DPYBIND11_CREATE_WITH_UV=3.13t\ncmake --build --preset venv\ncmake --build --preset venv -t cpptest\n```\n\nThe `default` preset will use an existing venv or Python install. If you'd like\nto run pytest yourself, say to easily control the options:\n\n```bash\ncd build\nsource .venv/bin/activate\ncd tests\npython -m pytest\n```\n\nThe `.so` file is not installed into the venv, so you need to run from this\ndirectory, the local directory is included with `python -m`.\n\n## Configuration options\n\nIn CMake, configuration options are given with \"-D\". Options are stored in the\nbuild directory, in the `CMakeCache.txt` file, so they are remembered for each\nbuild directory. Two selections are special - the generator, given with `-G`,\nand the compiler, which is selected based on environment variables `CXX` and\nsimilar, or `-DCMAKE_CXX_COMPILER=`. Unlike the others, these cannot be changed\nafter the initial run.\n\nThe valid options are:\n\n* `-DCMAKE_BUILD_TYPE`: Release, Debug, MinSizeRel, RelWithDebInfo\n* `-DPYBIND11_FINDPYTHON=ON`: Use CMake 3.12+'s FindPython instead of the\n classic, deprecated, custom FindPythonLibs\n* `-DPYBIND11_NOPYTHON=ON`: Disable all Python searching (disables tests)\n* `-DBUILD_TESTING=ON`: Enable the tests\n* `-DDOWNLOAD_CATCH=ON`: Download catch to build the C++ tests\n* `-DDOWNLOAD_EIGEN=ON`: Download Eigen for the NumPy tests\n* `-DPYBIND11_INSTALL=ON/OFF`: Enable the install target (on by default for the\n master project)\n* `-DUSE_PYTHON_INSTALL_DIR=ON`: Try to install into the python dir\n\n\n
A few standard CMake tricks: (click to expand)

\n\n* Use `cmake --build build -v` to see the commands used to build the files.\n* Use `cmake build -LH` to list the CMake options with help.\n* Use `ccmake` if available to see a curses (terminal) gui, or `cmake-gui` for\n a completely graphical interface (not present in the PyPI package).\n* Use `cmake --build build -j12` to build with 12 cores (for example).\n* Use `-G` and the name of a generator to use something different. `cmake\n --help` lists the generators available.\n - On Unix, setting `CMAKE_GENERATOR=Ninja` in your environment will give\n you automatic multithreading on all your CMake projects!\n* Open the `CMakeLists.txt` with QtCreator to generate for that IDE.\n* You can use `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` to generate the `.json` file\n that some tools expect.\n\n

\n\n\nTo run the tests, you can \"build\" the check target:\n\n```bash\ncmake --build build --target check\n```\n\n`--target` can be spelled `-t`. You can also run individual tests with these\ntargets:\n\n* `pytest`: Python tests only, using the\n[pytest](https://docs.pytest.org/en/stable/) framework\n* `cpptest`: C++ tests only\n* `test_cmake_build`: Install / subdirectory tests\n\nIf you want to build just a subset of tests, use\n`-DPYBIND11_TEST_OVERRIDE=\"test_callbacks;test_pickling\"`. If this is\nempty, all tests will be built. Tests are specified without an extension if they need both a .py and\n.cpp file.\n\nYou may also pass flags to the `pytest` target by editing `tests/pytest.ini` or\nby using the `PYTEST_ADDOPTS` environment variable\n(see [`pytest` docs](https://docs.pytest.org/en/2.7.3/customize.html#adding-default-options)). As an example:\n\n```bash\nenv PYTEST_ADDOPTS=\"--capture=no --exitfirst\" \\\n cmake --build build --target pytest\n# Or using abbreviated flags\nenv PYTEST_ADDOPTS=\"-s -x\" cmake --build build --target pytest\n```\n\n### Formatting\n\nAll formatting is handled by pre-commit.\n\nInstall with brew (macOS) or pip (any OS):\n\n```bash\n# Any OS\npython3 -m pip install pre-commit\n\n# OR macOS with homebrew:\nbrew install pre-commit\n```\n\nThen, you can run it on the items you've added to your staging area, or all\nfiles:\n\n```bash\npre-commit run\n# OR\npre-commit run --all-files\n```\n\nAnd, if you want to always use it, you can install it as a git hook (hence the\nname, pre-commit):\n\n```bash\npre-commit install\n```\n\n### Clang-Format\n\nAs of v2.6.2, pybind11 ships with a [`clang-format`][clang-format]\nconfiguration file at the top level of the repo (the filename is\n`.clang-format`). Currently, formatting is NOT applied automatically, but\nmanually using `clang-format` for newly developed files is highly encouraged.\nTo check if a file needs formatting:\n\n```bash\nclang-format -style=file --dry-run some.cpp\n```\n\nThe output will show things to be fixed, if any. To actually format the file:\n\n```bash\nclang-format -style=file -i some.cpp\n```\n\nNote that the `-style-file` option searches the parent directories for the\n`.clang-format` file, i.e. the commands above can be run in any subdirectory\nof the pybind11 repo.\n\n### Clang-Tidy\n\n[`clang-tidy`][clang-tidy] performs deeper static code analyses and is\nmore complex to run, compared to `clang-format`, but support for `clang-tidy`\nis built into the pybind11 CMake configuration. To run `clang-tidy`, the\nfollowing recipe should work. Run the `docker` command from the top-level\ndirectory inside your pybind11 git clone.\n\n```bash\ndocker run --rm -v $PWD:/pybind11 -w /pybind11 -it silkeh/clang:20\napt-get update && apt-get install -y git python3-dev python3-pytest ninja-build\ncmake --preset tidy\ncmake --build --preset tidy\n```\n\nYou can add `--fix` to the options list in the preset if you want to apply fixes\n(remember `-j1` to run only one thread).\n\n### Include what you use\n\nTo run include what you use, install (`brew install include-what-you-use` on\nmacOS), then run:\n\n```bash\ncmake -S . -B build-iwyu -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE=$(which include-what-you-use)\ncmake --build build-iwyu\n```\n\nThe report is sent to stderr; you can pipe it into a file if you wish.\n\n### Build recipes\n\nThis builds with the Intel compiler (assuming it is in your path, along with a\nrecent CMake and Python):\n\n```bash\npython3 -m venv venv\n. venv/bin/activate\npip install pytest\ncmake -S . -B build-intel -DCMAKE_CXX_COMPILER=$(which icpc) -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON -DPYBIND11_WERROR=ON\n```\n\nThis will test the PGI compilers:\n\n```bash\ndocker run --rm -it -v $PWD:/pybind11 nvcr.io/hpc/pgi-compilers:ce\napt-get update && apt-get install -y python3-dev python3-pip python3-pytest\nwget -qO- \"https://cmake.org/files/v3.18/cmake-3.18.2-Linux-x86_64.tar.gz\" | tar --strip-components=1 -xz -C /usr/local\ncmake -S pybind11/ -B build\ncmake --build build\n```\n\n### Explanation of the SDist/wheel building design\n\n> These details below are _only_ for packaging the Python sources from git. The\n> SDists and wheels created do not have any extra requirements at all and are\n> completely normal.\n\nThe main objective of the packaging system is to create SDists (Python's source\ndistribution packages) and wheels (Python's binary distribution packages) that\ninclude everything that is needed to work with pybind11, and which can be\ninstalled without any additional dependencies. This is more complex than it\nappears: in order to support CMake as a first class language even when using\nthe PyPI package, they must include the _generated_ CMake files (so as not to\nrequire CMake when installing the `pybind11` package itself). They should also\nprovide the option to install to the \"standard\" location\n(`/include/pybind11` and `/share/cmake/pybind11`) so they are\neasy to find with CMake, but this can cause problems if you are not an\nenvironment or using ``pyproject.toml`` requirements. This was solved by having\ntwo packages; the \"nice\" pybind11 package that stores the includes and CMake\nfiles inside the package, that you get access to via functions in the package,\nand a `pybind11-global` package that can be included via `pybind11[global]` if\nyou want the more invasive but discoverable file locations.\n\nIf you want to package the GitHub source for the \"global\" package, you need\nto use nox. Normal packaging will only make the normal package.\n\n\n```bash\nnox -s build\nnox -s build_global\n```\n\n\n[pre-commit]: https://pre-commit.com\n[clang-format]: https://clang.llvm.org/docs/ClangFormat.html\n[clang-tidy]: https://clang.llvm.org/extra/clang-tidy/\n[pybind11.readthedocs.org]: http://pybind11.readthedocs.org/en/latest\n[issue tracker]: https://github.com/pybind/pybind11/issues\n[gitter]: https://gitter.im/pybind/Lobby\n[using pull requests]: https://help.github.com/articles/using-pull-requests\n" }, { "path": ".github/ISSUE_TEMPLATE/bug-report.yml", "content": "name: Bug Report\ndescription: File an issue about a bug\ntitle: \"[BUG]: \"\nlabels: [triage]\nbody:\n - type: markdown\n attributes:\n value: |\n Please do your best to make the issue as easy to act on as possible, and only submit here if there is clearly a problem with pybind11 (ask first if unsure). **Note that a reproducer in a PR is much more likely to get immediate attention.**\n\n - type: checkboxes\n id: steps\n attributes:\n label: Required prerequisites\n description: Make sure you've completed the following steps before submitting your issue -- thank you!\n options:\n - label: Make sure you've read the [documentation](https://pybind11.readthedocs.io). Your issue may be addressed there.\n required: true\n - label: Search the [issue tracker](https://github.com/pybind/pybind11/issues) and [Discussions](https:/pybind/pybind11/discussions) to verify that this hasn't already been reported. +1 or comment there if it has.\n required: true\n - label: Consider asking first in the [Gitter chat room](https://gitter.im/pybind/Lobby) or in a [Discussion](https:/pybind/pybind11/discussions/new).\n required: false\n\n - type: input\n id: version\n attributes:\n label: What version (or hash if on master) of pybind11 are you using?\n validations:\n required: true\n\n - type: textarea\n id: description\n attributes:\n label: Problem description\n placeholder: >-\n Provide a short description, state the expected behavior and what\n actually happens. Include relevant information like what version of\n pybind11 you are using, what system you are on, and any useful commands\n / output.\n validations:\n required: true\n\n - type: textarea\n id: code\n attributes:\n label: Reproducible example code\n placeholder: >-\n The code should be minimal, have no external dependencies, isolate the\n function(s) that cause breakage. Submit matched and complete C++ and\n Python snippets that can be easily compiled and run to diagnose the\n issue. — Note that a reproducer in a PR is much more likely to get\n immediate attention: failing tests in the pybind11 CI are the best\n starting point for working out fixes.\n render: text\n\n - type: input\n id: regression\n attributes:\n label: Is this a regression? Put the last known working version here if it is.\n description: Put the last known working version here if this is a regression.\n value: Not a regression\n" }, { "path": ".github/ISSUE_TEMPLATE/config.yml", "content": "blank_issues_enabled: false\ncontact_links:\n - name: Ask a question\n url: https://github.com/pybind/pybind11/discussions/new\n about: Please ask and answer questions here, or propose new ideas.\n - name: Gitter room\n url: https://gitter.im/pybind/Lobby\n about: A room for discussing pybind11 with an active community\n" }, { "path": ".github/dependabot.yml", "content": "version: 2\nupdates:\n # Maintain dependencies for GitHub Actions\n - package-ecosystem: \"github-actions\"\n directory: \"/\"\n schedule:\n interval: \"monthly\"\n groups:\n actions:\n patterns:\n - \"*\"\n" }, { "path": ".github/labeler.yml", "content": "docs:\n all:\n - changed-files:\n - all-globs-to-all-files:\n - '!docs/changelog.md'\n - '!docs/upgrade.rst'\n - base-branch: \"^(?!dependabot).*\"\n - base-branch: \"^(?!pre-commit-ci).*\"\n\nci:\n - changed-files:\n - any-glob-to-any-file:\n - '.github/workflows/*.yml'\n" }, { "path": ".github/labeler_merged.yml", "content": "# Add 'needs changelog` label to any change to code files as long as the `CHANGELOG` hasn't changed\n# Skip dependabot and pre-commit-ci PRs\nneeds changelog:\n - all:\n - changed-files:\n - all-globs-to-all-files: \"!docs/changelog.md\"\n - base-branch: \"^(?!dependabot).*\"\n - base-branch: \"^(?!pre-commit-ci).*\"\n" }, { "path": ".github/matchers/pylint.json", "content": "{\n \"problemMatcher\": [\n {\n \"severity\": \"warning\",\n \"pattern\": [\n {\n \"regexp\": \"^([^:]+):(\\\\d+):(\\\\d+): ([A-DF-Z]\\\\d+): \\\\033\\\\[[\\\\d;]+m([^\\\\033]+).*$\",\n \"file\": 1,\n \"line\": 2,\n \"column\": 3,\n \"code\": 4,\n \"message\": 5\n }\n ],\n \"owner\": \"pylint-warning\"\n },\n {\n \"severity\": \"error\",\n \"pattern\": [\n {\n \"regexp\": \"^([^:]+):(\\\\d+):(\\\\d+): (E\\\\d+): \\\\033\\\\[[\\\\d;]+m([^\\\\033]+).*$\",\n \"file\": 1,\n \"line\": 2,\n \"column\": 3,\n \"code\": 4,\n \"message\": 5\n }\n ],\n \"owner\": \"pylint-error\"\n }\n ]\n}\n" }, { "path": ".github/pull_request_template.md", "content": "\n## Description\n\n\n\n\n## Suggested changelog entry:\n\n\n\n* Placeholder.\n" }, { "path": ".github/workflows/ci.yml", "content": "name: CI\n\non:\n workflow_dispatch:\n pull_request:\n types:\n - opened\n - synchronize\n - reopened\n - ready_for_review\n\npermissions: read-all\n\nconcurrency:\n group: test-${{ github.ref }}\n cancel-in-progress: true\n\nenv:\n PYTHONDEVMODE: 1\n PIP_BREAK_SYSTEM_PACKAGES: 1\n PIP_ONLY_BINARY: numpy\n FORCE_COLOR: 3\n PYTEST_TIMEOUT: 300\n # For cmake:\n VERBOSE: 1\n CMAKE_COLOR_DIAGNOSTICS: 1\n\njobs:\n # This is the \"main\" test suite, which tests a large number of different\n # versions of default compilers and Python versions in GitHub Actions.\n # It is in two parts: one that always runs, and one that runs on non-draft\n standard-small:\n if: github.event.action != 'ready_for_review'\n strategy:\n fail-fast: false\n matrix:\n include:\n - runs-on: ubuntu-22.04\n python-version: '3.8'\n cmake-args: -DPYBIND11_FINDPYTHON=OFF -DPYBIND11_NUMPY_1_ONLY=ON\n - runs-on: ubuntu-latest\n python-version: '3.13'\n cmake-args: -DCMAKE_CXX_STANDARD=23 -DPYBIND11_SIMPLE_GIL_MANAGEMENT=ON\n - runs-on: ubuntu-latest\n python-version: '3.14t'\n cmake-args: -DCMAKE_CXX_STANDARD=17 -DPYBIND11_TEST_SMART_HOLDER=ON\n - runs-on: ubuntu-latest\n python-version: 'pypy3.11'\n cmake-args: -DCMAKE_CXX_STANDARD=17\n - runs-on: ubuntu-latest\n python-version: 'graalpy-24.2'\n cmake-args: -DCMAKE_CXX_STANDARD=20\n - runs-on: macos-latest\n python-version: '3.14'\n cmake-args: -DCMAKE_CXX_STANDARD=14\n - runs-on: windows-2022\n python-version: '3.8'\n cmake-args: -DPYBIND11_FINDPYTHON=OFF\n\n\n name: 🐍\n uses: ./.github/workflows/reusable-standard.yml\n with:\n runs-on: ${{ matrix.runs-on }}\n python-version: ${{ matrix.python-version }}\n cmake-args: ${{ matrix.cmake-args }}\n\n standard-large:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n - runs-on: ubuntu-latest\n python-version: '3.8'\n cmake-args: -DPYBIND11_FINDPYTHON=ON -DCMAKE_CXX_STANDARD=17\n - runs-on: ubuntu-latest\n python-version: '3.10'\n cmake-args: -DCMAKE_CXX_STANDARD=20\n - runs-on: ubuntu-latest\n python-version: '3.11'\n cmake-args: -DPYBIND11_TEST_SMART_HOLDER=ON -DCMAKE_CXX_STANDARD=17\n - runs-on: ubuntu-latest\n python-version: '3.12'\n cmake-args: -DPYBIND11_TEST_SMART_HOLDER=ON -DPYBIND11_SIMPLE_GIL_MANAGEMENT=ON\n - runs-on: ubuntu-latest\n python-version: '3.14t'\n cmake-args: -DCMAKE_CXX_STANDARD=20 -DPYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION=ON\n - runs-on: ubuntu-latest\n python-version: '3.14'\n cmake-args: -DCMAKE_CXX_STANDARD=14\n - runs-on: ubuntu-latest\n python-version: 'pypy-3.10'\n cmake-args: -DCMAKE_CXX_STANDARD=14\n - runs-on: ubuntu-latest\n python-version: 'graalpy-24.1'\n\n # No SciPy for macOS ARM\n - runs-on: macos-15-intel\n python-version: '3.8'\n cmake-args: -DCMAKE_CXX_STANDARD=14\n - runs-on: macos-15-intel\n python-version: '3.11'\n cmake-args: -DPYBIND11_TEST_SMART_HOLDER=ON\n - runs-on: macos-15-intel\n python-version: '3.13'\n cmake-args: -DCMAKE_CXX_STANDARD=11\n - runs-on: macos-latest\n python-version: '3.12'\n cmake-args: -DCMAKE_CXX_STANDARD=17 -DPYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION=ON\n - runs-on: macos-latest\n python-version: '3.14t'\n cmake-args: -DCMAKE_CXX_STANDARD=20\n - runs-on: macos-15-intel\n python-version: 'pypy-3.10'\n cmake-args: -DCMAKE_CXX_STANDARD=17\n - runs-on: macos-latest\n python-version: 'pypy-3.11'\n - runs-on: macos-latest\n python-version: 'graalpy-24.2'\n\n - runs-on: windows-latest\n python-version: '3.9'\n cmake-args: -DPYBIND11_TEST_SMART_HOLDER=ON\n - runs-on: windows-2022\n python-version: '3.8'\n cmake-args: -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPYBIND11_NUMPY_1_ONLY=ON\n - runs-on: windows-2022\n python-version: '3.9'\n cmake-args: -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL -DCMAKE_CXX_STANDARD=14\n # This needs a python built with MTd\n # - runs-on: windows-2022\n # python-version: '3.11'\n # cmake-args: -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDebug\n - runs-on: windows-2022\n python-version: '3.10'\n cmake-args: -DPYBIND11_TEST_SMART_HOLDER=ON -DCMAKE_CXX_FLAGS=\"/GR /EHsc\"\n - runs-on: windows-2022\n python-version: '3.13'\n cmake-args: -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDebugDLL\n - runs-on: windows-latest\n python-version: '3.14'\n cmake-args: -DCMAKE_CXX_STANDARD=20\n - runs-on: windows-latest\n python-version: '3.14t'\n cmake-args: -DCMAKE_CXX_STANDARD=23\n - runs-on: windows-latest\n python-version: 'pypy-3.10'\n cmake-args: -DCMAKE_CXX_STANDARD=17\n - runs-on: windows-latest\n python-version: 'pypy3.11'\n cmake-args: -DCMAKE_CXX_STANDARD=20\n # The setup-python action currently doesn't have graalpy for windows\n # See https://github.com/actions/setup-python/pull/880\n\n name: 🐍\n uses: ./.github/workflows/reusable-standard.yml\n with:\n runs-on: ${{ matrix.runs-on }}\n python-version: ${{ matrix.python-version }}\n cmake-args: ${{ matrix.cmake-args }}\n\n # This checks inplace builds with C++11\n inplace:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n - runs-on: ubuntu-latest\n python-version: '3.9'\n - runs-on: macos-latest\n python-version: '3.12'\n - runs-on: windows-latest\n python-version: '3.11'\n\n name: \"🐍 ${{ matrix.python-version }} • ${{ matrix.runs-on }} • x64 inplace C++14\"\n runs-on: ${{ matrix.runs-on }}\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python ${{ matrix.python-version }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ matrix.python-version }}\n allow-prereleases: true\n\n - name: Install uv\n uses: astral-sh/setup-uv@v7\n with:\n enable-cache: true\n\n - name: Prepare env\n run: uv pip install --python=python --system -r tests/requirements.txt\n\n # TODO Resolve Windows Ninja shared object issue on Python 3.8+\n - name: Use Ninja except on Windows\n if: runner.os != 'Windows'\n run: echo \"CMAKE_GENERATOR=Ninja\" >> \"$GITHUB_ENV\"\n\n # More-or-less randomly adding a few extra flags here.\n # In particular, use this one to test the next ABI bump (internals version).\n - name: Configure\n run: >\n cmake -S. -B.\n -DPYBIND11_WERROR=ON\n -DPYBIND11_SIMPLE_GIL_MANAGEMENT=ON\n -DPYBIND11_PYTEST_ARGS=-v\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=14\n -DPYBIND11_INTERNALS_VERSION=10000000\n\n # Checks to makes sure defining `_` is allowed\n # Triggers EHsc missing error on Windows\n - name: Add underscore check\n if: runner.os != 'Windows'\n run: cmake -S. -B. -DCMAKE_CXX_FLAGS=\"-D_=1\"\n\n - name: Build\n run: cmake --build .\n\n - name: Python tests\n run: cmake --build . --target pytest\n\n - name: Compiled tests\n timeout-minutes: 3\n run: cmake --build . --target cpptest\n\n - name: Interface test\n run: cmake --build . --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build . --target test_cross_module_rtti\n\n\n manylinux:\n name: Manylinux on 🐍 ${{ matrix.python-version }} (${{ matrix.container }})\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n - container: quay.io/pypa/manylinux_2_28_x86_64:latest\n python-version: '3.13t'\n - container: quay.io/pypa/musllinux_1_2_x86_64:latest\n python-version: '3.13t'\n - container: quay.io/pypa/manylinux_2_28_x86_64:latest\n python-version: '3.14t'\n - container: quay.io/pypa/musllinux_1_2_x86_64:latest\n python-version: '3.14t'\n runs-on: ubuntu-latest\n timeout-minutes: 40\n container: ${{ matrix.container }}\n steps:\n - uses: actions/checkout@v6\n with:\n fetch-depth: 0\n\n - name: Prepare uv's path\n run: echo \"$HOME/.local/bin\" >> $GITHUB_PATH\n\n - name: Install ninja\n run: uv tool install ninja\n\n - name: Configure via preset\n run: cmake --preset venv -DPYBIND11_CREATE_WITH_UV=\"${{ matrix.python-version }}\"\n\n - name: Build C++11\n run: cmake --build --preset venv\n\n - name: Python tests C++11\n run: cmake --build --preset testsvenv -t pytest\n\n deadsnakes:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n # TODO: Fails on 3.10, investigate\n # JOB DISABLED (NEEDS WORK): https://github.com/pybind/pybind11/issues/4889\n # - python-version: \"3.9\"\n # python-debug: true\n # valgrind: true\n - python-version: \"3.11\"\n python-debug: false\n\n name: \"🐍 ${{ matrix.python-version }}${{ matrix.python-debug && '-dbg' || '' }} (deadsnakes)${{ matrix.valgrind && ' • Valgrind' || '' }} • x64\"\n runs-on: ubuntu-latest\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python ${{ matrix.python-version }} (deadsnakes)\n uses: deadsnakes/action@v3.2.0\n with:\n python-version: ${{ matrix.python-version }}\n debug: ${{ matrix.python-debug }}\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Valgrind cache\n if: matrix.valgrind\n uses: actions/cache@v5\n id: cache-valgrind\n with:\n path: valgrind\n key: 3.16.1 # Valgrind version\n\n - name: Compile Valgrind\n if: matrix.valgrind && steps.cache-valgrind.outputs.cache-hit != 'true'\n run: |\n VALGRIND_VERSION=3.16.1\n curl https://sourceware.org/pub/valgrind/valgrind-$VALGRIND_VERSION.tar.bz2 -o - | tar xj\n mv valgrind-$VALGRIND_VERSION valgrind\n cd valgrind\n ./configure\n make -j 2 > /dev/null\n\n - name: Install Valgrind\n if: matrix.valgrind\n working-directory: valgrind\n run: |\n sudo make install\n sudo apt-get update\n sudo apt-get install ninja-build libc6-dbg\n\n - name: Prepare env\n run: |\n python -m pip install -r tests/requirements.txt\n\n - name: Configure\n run: cmake --preset default -DCMAKE_CXX_STANDARD=17\n\n - name: Build\n run: cmake --build --preset default\n\n - name: Python tests\n run: cmake --build --preset default --target pytest\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build --preset default --target cpptest\n\n - name: Visibility test\n run: cmake --build --preset default --target test_cross_module_rtti\n\n - name: Run Valgrind on Python tests\n if: matrix.valgrind\n run: cmake --build --preset default --target memcheck\n\n\n # Testing on clang using the excellent silkeh clang docker images\n clang:\n if: github.event.pull_request.draft == false\n runs-on: ubuntu-latest\n strategy:\n fail-fast: false\n matrix:\n include:\n - clang: 5\n std: 14\n - clang: 11\n std: 20\n - clang: 14\n std: 20\n - clang: 16\n std: 20\n container_suffix: \"-bullseye\"\n - clang: 18\n std: 20\n cxx_flags: \"-Werror -Wall -Wextra -Wwrite-strings -Wunreachable-code -Wpointer-arith -Wredundant-decls\"\n container_suffix: \"-bookworm\"\n\n name: \"🐍 3 • Clang ${{ matrix.clang }} • C++${{ matrix.std }} • x64${{ matrix.cxx_flags && ' • cxx_flags' || '' }}\"\n container: \"silkeh/clang:${{ matrix.clang }}${{ matrix.container_suffix }}\"\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Add wget and python3\n run: apt-get update && apt-get install -y python3-dev python3-numpy python3-pytest libeigen3-dev\n\n - name: Configure\n shell: bash\n run: >\n cmake -S . -B build\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DCMAKE_CXX_STANDARD=${{ matrix.std }}\n -DCMAKE_CXX_FLAGS=\"${{ matrix.cxx_flags }}\"\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n\n - name: Build\n run: cmake --build build -j 2\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build build --target cpptest\n\n - name: Interface test\n run: cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti\n\n # Testing NVCC; forces sources to behave like .cu files\n cuda:\n runs-on: ubuntu-latest\n name: \"🐍 3.10 • CUDA 12.2 • Ubuntu 22.04\"\n container: nvidia/cuda:12.2.0-devel-ubuntu22.04\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n # tzdata will try to ask for the timezone, so set the DEBIAN_FRONTEND\n - name: Install 🐍 3\n run: apt-get update && DEBIAN_FRONTEND=\"noninteractive\" apt-get install -y cmake git python3-dev python3-pytest python3-numpy\n\n - name: Configure\n run: cmake -S . -B build -DPYBIND11_CUDA_TESTS=ON -DPYBIND11_WERROR=ON -DDOWNLOAD_CATCH=ON\n\n - name: Build\n run: cmake --build build -j2 --verbose\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n\n# TODO: Internal compiler error - report to NVidia\n# # Testing CentOS 8 + PGI compilers\n# centos-nvhpc8:\n# runs-on: ubuntu-latest\n# name: \"🐍 3 • CentOS8 / PGI 20.11 • x64\"\n# container: centos:8\n#\n# steps:\n# - uses: actions/checkout@v6\n#\n# - name: Add Python 3 and a few requirements\n# run: yum update -y && yum install -y git python3-devel python3-numpy python3-pytest make environment-modules\n#\n# - name: Install CMake with pip\n# run: |\n# python3 -m pip install --upgrade pip\n# python3 -m pip install cmake --prefer-binary\n#\n# - name: Install NVidia HPC SDK\n# run: >\n# yum -y install\n# https://developer.download.nvidia.com/hpc-sdk/20.11/nvhpc-20-11-20.11-1.x86_64.rpm\n# https://developer.download.nvidia.com/hpc-sdk/20.11/nvhpc-2020-20.11-1.x86_64.rpm\n#\n# - name: Configure\n# shell: bash\n# run: |\n# source /etc/profile.d/modules.sh\n# module load /opt/nvidia/hpc_sdk/modulefiles/nvhpc/20.11\n# cmake -S . -B build -DDOWNLOAD_CATCH=ON -DCMAKE_CXX_STANDARD=14 -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n#\n# - name: Build\n# run: cmake --build build -j 2 --verbose\n#\n# - name: Python tests\n# run: cmake --build build --target pytest\n#\n# - name: C++ tests\n# run: cmake --build build --target cpptest\n#\n# - name: Interface test\n# run: cmake --build build --target test_cmake_build\n\n\n # Testing on Ubuntu + NVHPC (previous PGI) compilers, which seems to require more workarounds\n ubuntu-nvhpc:\n if: github.event.pull_request.draft == false\n runs-on: ubuntu-24.04\n name: \"🐍 3 • NVHPC 25.11 • C++17 • x64\"\n timeout-minutes: 90\n\n env:\n # tzdata will try to ask for the timezone, so set the DEBIAN_FRONTEND\n DEBIAN_FRONTEND: 'noninteractive'\n steps:\n - uses: actions/checkout@v6\n\n - name: Clean out unused stuff to save space\n run: |\n sudo rm -rf /usr/local/lib/android /usr/share/dotnet /opt/ghc /opt/hostedtoolcache/CodeQL\n sudo apt-get clean\n\n - name: Add NVHPC Repo\n run: |\n echo 'deb [trusted=yes] https://developer.download.nvidia.com/hpc-sdk/ubuntu/amd64 /' | \\\n sudo tee /etc/apt/sources.list.d/nvhpc.list\n\n - name: Install 🐍 3 & NVHPC\n run: |\n sudo apt-get update -y\n sudo apt-get install -y cmake environment-modules git python3-dev python3-pip python3-numpy\n sudo apt-get install -y --no-install-recommends nvhpc-25-11\n sudo rm -rf /var/lib/apt/lists/*\n apt-cache depends nvhpc-25-11\n python3 -m pip install --upgrade pip\n python3 -m pip install --upgrade pytest\n\n # On some systems, you many need further workarounds:\n # https://github.com/pybind/pybind11/pull/2475\n - name: Configure\n shell: bash\n run: |\n source /etc/profile.d/modules.sh\n module load /opt/nvidia/hpc_sdk/modulefiles/nvhpc/25.11\n cmake -S . -B build -DDOWNLOAD_CATCH=ON \\\n -DCMAKE_CXX_STANDARD=17 \\\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\") \\\n -DCMAKE_CXX_FLAGS=\"-Wc,--pending_instantiations=0\" \\\n -DPYBIND11_TEST_FILTER=\"test_smart_ptr.cpp\"\n\n - name: Build\n run: cmake --build build -j $(nproc) --verbose\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build build --target cpptest\n\n - name: Interface test\n run: cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti\n\n # Testing on GCC using the GCC docker images (only recent images supported)\n gcc:\n if: github.event.pull_request.draft == false\n runs-on: ubuntu-latest\n strategy:\n fail-fast: false\n matrix:\n include:\n - { gcc: 9, std: 20 }\n - { gcc: 10, std: 17 }\n - { gcc: 10, std: 20 }\n - { gcc: 13, std: 20, cxx_flags: \"-Wall -Wextra -Wwrite-strings -Wunreachable-code -Wpointer-arith -Wredundant-decls\" }\n\n name: \"🐍 3 • GCC ${{ matrix.gcc }} • C++${{ matrix.std }} • x64${{ matrix.cxx_flags && ' • cxx_flags' || '' }}\"\n container: \"gcc:${{ matrix.gcc }}\"\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Add Python 3\n run: apt-get update; apt-get install -y python3-dev python3-numpy python3-pytest python3-pip libeigen3-dev\n\n - name: Update pip\n run: python3 -m pip install --upgrade pip\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Configure\n shell: bash\n run: >\n cmake -S . -B build\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DCMAKE_CXX_STANDARD=${{ matrix.std }}\n -DCMAKE_CXX_FLAGS=\"${{ matrix.cxx_flags }}\"\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n\n - name: Build\n run: cmake --build build -j 2\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build build --target cpptest\n\n - name: Interface test\n run: cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti\n\n - name: Configure - Exercise cmake -DPYBIND11_TEST_OVERRIDE\n if: matrix.gcc == '12'\n shell: bash\n run: >\n cmake -S . -B build_partial\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DCMAKE_CXX_STANDARD=${{ matrix.std }}\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n \"-DPYBIND11_TEST_OVERRIDE=test_call_policies.cpp;test_gil_scoped.cpp;test_thread.cpp\"\n\n - name: Build - Exercise cmake -DPYBIND11_TEST_OVERRIDE\n if: matrix.gcc == '12'\n run: cmake --build build_partial -j 2\n\n - name: Python tests - Exercise cmake -DPYBIND11_TEST_OVERRIDE\n if: matrix.gcc == '12'\n run: cmake --build build_partial --target pytest\n\n # Testing on ICC using the oneAPI apt repo\n icc:\n if: github.event.pull_request.draft == false\n runs-on: ubuntu-22.04\n timeout-minutes: 90\n\n name: \"🐍 3 • ICC latest • x64\"\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Add apt repo\n run: |\n sudo apt-get update\n sudo apt-get install -y wget build-essential pkg-config cmake ca-certificates gnupg\n wget https://apt.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS-2023.PUB\n sudo apt-key add GPG-PUB-KEY-INTEL-SW-PRODUCTS-2023.PUB\n echo \"deb https://apt.repos.intel.com/oneapi all main\" | sudo tee /etc/apt/sources.list.d/oneAPI.list\n\n - name: Add ICC & Python 3\n run: sudo apt-get update; sudo apt-get install -y intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic cmake python3-dev python3-numpy python3-pytest python3-pip\n\n - name: Update pip\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n python3 -m pip install --upgrade pip\n\n - name: Install dependencies\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n python3 -m pip install -r tests/requirements.txt\n\n - name: Configure C++11\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake -S . -B build-11 \\\n -DPYBIND11_WERROR=ON \\\n -DDOWNLOAD_CATCH=ON \\\n -DDOWNLOAD_EIGEN=OFF \\\n -DCMAKE_CXX_STANDARD=11 \\\n -DCMAKE_CXX_COMPILER=$(which icpc) \\\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n\n - name: Build C++11\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-11 -j 2 -v\n\n - name: Python tests C++11\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n sudo service apport stop\n cmake --build build-11 --target check\n\n - name: C++ tests C++11\n timeout-minutes: 3\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-11 --target cpptest\n\n - name: Interface test C++11\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-11 --target test_cmake_build\n\n - name: Visibility test\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-11 --target test_cross_module_rtti\n\n - name: Configure C++17\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake -S . -B build-17 \\\n -DPYBIND11_WERROR=ON \\\n -DDOWNLOAD_CATCH=ON \\\n -DDOWNLOAD_EIGEN=OFF \\\n -DCMAKE_CXX_STANDARD=17 \\\n -DCMAKE_CXX_COMPILER=$(which icpc) \\\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n\n - name: Build C++17\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-17 -j 2 -v\n\n - name: Python tests C++17\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n sudo service apport stop\n cmake --build build-17 --target check\n\n - name: C++ tests C++17\n timeout-minutes: 3\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-17 --target cpptest\n\n - name: Interface test C++17\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-17 --target test_cmake_build\n\n - name: Visibility test\n run: |\n set +e; source /opt/intel/oneapi/setvars.sh; set -e\n cmake --build build-17 --target test_cross_module_rtti\n\n # Testing on CentOS (manylinux uses a centos base).\n centos:\n if: github.event.pull_request.draft == false\n runs-on: ubuntu-latest\n strategy:\n fail-fast: false\n matrix:\n container:\n - \"almalinux:8\"\n - \"almalinux:9\"\n\n name: \"🐍 3 • ${{ matrix.container }} • x64\"\n container: \"${{ matrix.container }}\"\n timeout-minutes: 90\n\n steps:\n - name: Latest actions/checkout\n uses: actions/checkout@v6\n\n - name: Add Python 3.8\n if: matrix.container == 'almalinux:8'\n run: dnf update -y && dnf install -y python38-devel gcc-c++ make git\n\n - name: Add Python 3 (default)\n if: matrix.container != 'almalinux:8'\n run: dnf update -y && dnf install -y python3-devel gcc-c++ make git\n\n - name: Update pip\n run: python3 -m pip install --upgrade pip\n\n - name: Install dependencies\n run: |\n python3 -m pip install cmake -r tests/requirements.txt\n\n - name: Ensure NumPy 2 is used (required Python >= 3.9)\n if: matrix.container == 'almalinux:9'\n run: |\n python3 -m pip install 'numpy>=2.0.0b1' 'scipy>=1.13.0rc1'\n\n - name: Configure\n shell: bash\n run: >\n cmake -S . -B build\n -DCMAKE_BUILD_TYPE=MinSizeRel\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=11\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n\n - name: Build\n run: cmake --build build -j 2\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build build --target cpptest\n\n - name: Interface test\n run: cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti\n\n\n # This tests an \"install\" with the CMake tools\n install-classic:\n if: github.event.pull_request.draft == false\n name: \"🐍 3.9 • Debian • x86 • Install\"\n runs-on: ubuntu-latest\n container: i386/debian:bullseye\n timeout-minutes: 90\n\n steps:\n # v1 required for i386/debian container; pinned to SHA to prevent dependabot updates\n - uses: actions/checkout@544eadc6bf3d226fd7a7a9f0dc5b5bf7ca0675b9 # v1\n\n - name: Install requirements\n run: |\n apt-get update\n apt-get install -y git make cmake g++ libeigen3-dev python3-dev python3-pip\n pip3 install \"pytest==6.*\"\n\n - name: Configure for install\n run: >\n cmake .\n -DPYBIND11_INSTALL=1 -DPYBIND11_TEST=0\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n\n - name: Make and install\n run: make install\n\n - name: Copy tests to new directory\n run: cp -a tests /pybind11-tests\n\n - name: Make a new test directory\n run: mkdir /build-tests\n\n - name: Configure tests\n run: >\n cmake ../pybind11-tests\n -DDOWNLOAD_CATCH=ON\n -DPYBIND11_WERROR=ON\n -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\")\n working-directory: /build-tests\n\n - name: Python tests\n run: make pytest -j 2\n working-directory: /build-tests\n\n\n # This verifies that the documentation is not horribly broken, and does a\n # basic validation check on the SDist.\n doxygen:\n if: github.event.pull_request.draft == false\n name: \"Documentation build test\"\n runs-on: ubuntu-latest\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - uses: actions/setup-python@v6\n with:\n python-version: \"3.x\"\n\n - name: Install Doxygen\n run: sudo apt-get install -y doxygen librsvg2-bin # Changed to rsvg-convert in 20.04\n\n - name: Build docs\n run: pipx run nox -s docs\n\n - name: Make SDist\n run: pipx run nox -s build -- --sdist\n\n - run: git status --ignored\n\n - name: Check local include dir\n run: >\n ls pybind11;\n python3 -c \"import pybind11, pathlib; assert (a := pybind11.get_include()) == (b := str(pathlib.Path('include').resolve())), f'{a} != {b}'\"\n\n - name: Compare Dists (headers only)\n working-directory: include\n run: |\n python3 -m pip install --user -U ../dist/*.tar.gz\n installed=$(python3 -c \"import pybind11; print(pybind11.get_include() + '/pybind11')\")\n diff -rq $installed ./pybind11\n\n win32:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n - python: '3.8'\n args: -DCMAKE_CXX_STANDARD=17\n - python: '3.10'\n args: -DCMAKE_CXX_STANDARD=20\n - python: '3.13'\n\n\n name: \"🐍 ${{ matrix.python }} • MSVC 2022 • x86 ${{ matrix.args }}\"\n runs-on: windows-2022\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python ${{ matrix.python }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ matrix.python }}\n architecture: x86\n # Python 3.13.4 broken on Windows\n check-latest: >-\n ${{ matrix.python == '3.13' && runner.os == 'Windows' }}\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Prepare MSVC\n uses: ilammy/msvc-dev-cmd@v1.13.0\n with:\n arch: x86\n\n - name: Prepare env\n run: |\n python -m pip install -r tests/requirements.txt\n\n - name: Configure ${{ matrix.args }}\n run: >\n cmake -S . -B build\n -G \"Visual Studio 17 2022\" -A Win32\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n ${{ matrix.args }}\n - name: Build C++11\n run: cmake --build build -j 2\n\n - name: Python tests\n run: cmake --build build -t pytest\n\n win32-debug:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n - python: 3.9\n args: -DCMAKE_CXX_STANDARD=20\n - python: 3.8\n args: -DCMAKE_CXX_STANDARD=17\n\n name: \"🐍 ${{ matrix.python }} • MSVC 2022 (Debug) • x86 ${{ matrix.args }}\"\n runs-on: windows-2022\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python ${{ matrix.python }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ matrix.python }}\n architecture: x86\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Prepare MSVC\n uses: ilammy/msvc-dev-cmd@v1.13.0\n with:\n arch: x86\n\n - name: Prepare env\n run: |\n python -m pip install -r tests/requirements.txt\n\n - name: Configure ${{ matrix.args }}\n run: >\n cmake -S . -B build\n -G \"Visual Studio 17 2022\" -A Win32\n -DCMAKE_BUILD_TYPE=Debug\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n ${{ matrix.args }}\n - name: Build C++11\n run: cmake --build build --config Debug -j 2\n\n - name: Python tests\n run: cmake --build build --config Debug -t pytest\n\n\n windows-2022:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n python:\n - 3.9\n\n name: \"🐍 ${{ matrix.python }} • MSVC 2022 C++20 • x64\"\n runs-on: windows-2022\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python ${{ matrix.python }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ matrix.python }}\n\n - name: Prepare env\n run: python3 -m pip install -r tests/requirements.txt\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Configure C++20\n run: >\n cmake -S . -B build\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=20\n\n - name: Build C++20\n run: cmake --build build -j 2\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n - name: C++20 tests\n timeout-minutes: 3\n run: cmake --build build --target cpptest -j 2\n\n - name: Interface test C++20\n run: cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti\n\n - name: Configure C++20 - Exercise cmake -DPYBIND11_TEST_OVERRIDE\n run: >\n cmake -S . -B build_partial\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=20\n \"-DPYBIND11_TEST_OVERRIDE=test_call_policies.cpp;test_gil_scoped.cpp;test_thread.cpp\"\n\n - name: Build C++20 - Exercise cmake -DPYBIND11_TEST_OVERRIDE\n run: cmake --build build_partial -j 2\n\n - name: Python tests - Exercise cmake -DPYBIND11_TEST_OVERRIDE\n run: cmake --build build_partial --target pytest\n\n mingw:\n if: github.event.pull_request.draft == false\n name: \"🐍 3 • windows-latest • ${{ matrix.sys }}\"\n runs-on: windows-latest\n timeout-minutes: 90\n defaults:\n run:\n shell: msys2 {0}\n strategy:\n fail-fast: false\n matrix:\n include:\n - sys: mingw32\n env: i686\n extra_install: \"\"\n - sys: mingw64\n env: x86_64\n extra_install: |\n mingw-w64-x86_64-python-numpy\n mingw-w64-x86_64-python-scipy\n mingw-w64-x86_64-eigen3\n steps:\n - uses: msys2/setup-msys2@v2\n with:\n msystem: ${{matrix.sys}}\n install: >-\n git\n mingw-w64-${{matrix.env}}-gcc\n mingw-w64-${{matrix.env}}-python-pip\n mingw-w64-${{matrix.env}}-cmake\n mingw-w64-${{matrix.env}}-make\n mingw-w64-${{matrix.env}}-python-pytest\n mingw-w64-${{matrix.env}}-boost\n mingw-w64-${{matrix.env}}-catch\n ${{ matrix.extra_install }}\n\n - uses: actions/checkout@v6\n\n - name: Configure C++11\n # LTO leads to many undefined reference like\n # `pybind11::detail::function_call::function_call(pybind11::detail::function_call&&)\n run: >-\n cmake -G \"MinGW Makefiles\" -DCMAKE_CXX_STANDARD=11 -DPYBIND11_WERROR=ON -DDOWNLOAD_CATCH=ON\n -DPYTHON_EXECUTABLE=$(python -c \"import sys; print(sys.executable)\")\n -S . -B build\n\n - name: Build C++11\n run: cmake --build build -j 2\n\n - name: Python tests C++11\n run: cmake --build build --target pytest -j 2\n\n - name: C++11 tests\n timeout-minutes: 3\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build --target cpptest -j 2\n\n - name: Interface test C++11\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build --target test_cross_module_rtti\n\n - name: Clean directory\n run: git clean -fdx\n\n - name: Configure C++14\n run: >-\n cmake -G \"MinGW Makefiles\" -DCMAKE_CXX_STANDARD=14 -DPYBIND11_WERROR=ON -DDOWNLOAD_CATCH=ON\n -DPYTHON_EXECUTABLE=$(python -c \"import sys; print(sys.executable)\")\n -S . -B build2\n\n - name: Build C++14\n run: cmake --build build2 -j 2\n\n - name: Python tests C++14\n run: cmake --build build2 --target pytest -j 2\n\n - name: C++14 tests\n timeout-minutes: 3\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build2 --target cpptest -j 2\n\n - name: Interface test C++14\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build2 --target test_cmake_build\n\n - name: Visibility test\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build2 --target test_cross_module_rtti\n\n - name: Clean directory\n run: git clean -fdx\n\n - name: Configure C++17\n run: >-\n cmake -G \"MinGW Makefiles\" -DCMAKE_CXX_STANDARD=17 -DPYBIND11_WERROR=ON -DDOWNLOAD_CATCH=ON\n -DPYTHON_EXECUTABLE=$(python -c \"import sys; print(sys.executable)\")\n -S . -B build3\n\n - name: Build C++17\n run: cmake --build build3 -j 2\n\n - name: Python tests C++17\n run: cmake --build build3 --target pytest -j 2\n\n - name: C++17 tests\n timeout-minutes: 3\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build3 --target cpptest -j 2\n\n - name: Interface test C++17\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build3 --target test_cmake_build\n\n - name: Visibility test\n run: PYTHONHOME=/${{matrix.sys}} PYTHONPATH=/${{matrix.sys}} cmake --build build3 --target test_cross_module_rtti\n\n windows_clang:\n if: github.event.pull_request.draft == false\n\n strategy:\n matrix:\n os: [windows-latest]\n python: ['3.10']\n\n runs-on: \"${{ matrix.os }}\"\n timeout-minutes: 90\n\n name: \"🐍 ${{ matrix.python }} • ${{ matrix.os }} • clang-latest\"\n\n steps:\n - name: Show env\n run: env\n\n - name: Checkout\n uses: actions/checkout@v6\n\n - name: Set up Clang\n uses: egor-tensin/setup-clang@v2\n\n - name: Setup Python ${{ matrix.python }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ matrix.python }}\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Install ninja-build tool\n uses: seanmiddleditch/gha-setup-ninja@v6\n\n - name: Run pip installs\n run: |\n python -m pip install --upgrade pip\n python -m pip install -r tests/requirements.txt\n\n - name: Show Clang++ version\n run: clang++ --version\n\n - name: Show CMake version\n run: cmake --version\n\n # TODO: WERROR=ON\n - name: Configure Clang\n run: >\n cmake -G Ninja -S . -B .\n -DPYBIND11_WERROR=OFF\n -DPYBIND11_SIMPLE_GIL_MANAGEMENT=OFF\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_COMPILER=clang++\n -DCMAKE_CXX_STANDARD=17\n\n - name: Build\n run: cmake --build . -j 2\n\n - name: Python tests\n run: cmake --build . --target pytest -j 2\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build . --target cpptest -j 2\n\n - name: Interface test\n run: cmake --build . --target test_cmake_build -j 2\n\n - name: Visibility test\n run: cmake --build . --target test_cross_module_rtti -j 2\n\n - name: Clean directory\n run: git clean -fdx\n\n # Clang with MSVC/Windows SDK toolchain + python.org CPython (Windows ARM)\n windows_arm_clang_msvc:\n if: github.event.pull_request.draft == false\n\n strategy:\n fail-fast: false\n matrix:\n os: [windows-11-arm]\n python: ['3.13']\n\n runs-on: \"${{ matrix.os }}\"\n timeout-minutes: 90\n\n name: \"🐍 ${{ matrix.python }} • ${{ matrix.os }} • clang-msvc\"\n\n steps:\n - name: Show env\n run: env\n\n - name: Checkout\n uses: actions/checkout@v6\n\n - name: Setup Python ${{ matrix.python }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ matrix.python }}\n architecture: arm64\n\n - name: Run pip installs\n run: |\n python -m pip install --upgrade pip\n python -m pip install -r tests/requirements.txt\n\n - name: Configure CMake\n run: >\n cmake -G Ninja -S . -B .\n -DPYBIND11_WERROR=OFF\n -DPYBIND11_SIMPLE_GIL_MANAGEMENT=OFF\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_COMPILER=clang++\n -DCMAKE_CXX_STANDARD=20\n -DPython_ROOT_DIR=\"$env:Python_ROOT_DIR\"\n\n - name: Build\n run: cmake --build . -j 2\n\n - name: Python tests\n run: cmake --build . --target pytest -j 2\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build . --target cpptest -j 2\n\n - name: Interface test\n run: cmake --build . --target test_cmake_build -j 2\n\n - name: Visibility test\n run: cmake --build . --target test_cross_module_rtti -j 2\n\n # Clang in MSYS2/MinGW-w64 CLANGARM64 toolchain + MSYS2 Python (Windows ARM)\n windows_arm_clang_msys2:\n if: github.event.pull_request.draft == false\n\n strategy:\n fail-fast: false\n matrix:\n os: [windows-11-arm]\n\n runs-on: \"${{ matrix.os }}\"\n timeout-minutes: 90\n\n name: \"${{ matrix.os }} • clang-msys2\"\n\n defaults:\n run:\n shell: msys2 {0}\n\n steps:\n - uses: actions/checkout@v6\n with:\n submodules: true\n\n - uses: msys2/setup-msys2@v2\n with:\n msystem: CLANGARM64\n update: true\n install: |\n mingw-w64-clang-aarch64-cmake\n mingw-w64-clang-aarch64-clang\n mingw-w64-clang-aarch64-ninja\n mingw-w64-clang-aarch64-python-pip\n mingw-w64-clang-aarch64-python-pytest\n mingw-w64-clang-aarch64-python-numpy\n\n - name: Debug info\n run: |\n clang++ --version\n cmake --version\n ninja --version\n python --version\n\n - name: Run pip installs\n run: |\n python -m pip install --upgrade pip\n python -m pip install -r tests/requirements.txt\n\n - name: Configure CMake\n run: >-\n cmake -S . -B build\n -DPYBIND11_WERROR=OFF\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_COMPILER=clang++\n -DCMAKE_CXX_STANDARD=20\n -DPYTHON_EXECUTABLE=$(python -c \"import sys; print(sys.executable)\")\n\n - name: Build\n run: cmake --build build -j 2\n\n - name: Python tests\n run: cmake --build build --target pytest -j 2\n\n - name: C++ tests\n timeout-minutes: 3\n run: PYTHONHOME=/clangarm64 PYTHONPATH=/clangarm64 cmake --build build --target cpptest -j 2\n\n - name: Interface test\n run: cmake --build build --target test_cmake_build -j 2\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti -j 2\n" }, { "path": ".github/workflows/configure.yml", "content": "name: Config\n\non:\n workflow_dispatch:\n pull_request:\n types:\n - opened\n - synchronize\n - reopened\n - ready_for_review\n push:\n branches:\n - master\n - stable\n - v*\n\npermissions:\n contents: read\n\njobs:\n # This tests various versions of CMake in various combinations, to make sure\n # the configure step passes.\n cmake:\n if: github.event.pull_request.draft == false\n strategy:\n fail-fast: false\n matrix:\n include:\n - runs-on: ubuntu-22.04\n cmake: \"3.15\"\n\n - runs-on: ubuntu-24.04\n cmake: \"3.26\"\n\n - runs-on: ubuntu-24.04\n cmake: \"3.29\"\n\n - runs-on: macos-15-intel\n cmake: \"3.15\"\n\n - runs-on: macos-14\n cmake: \"4.2\"\n\n - runs-on: windows-latest\n cmake: \"4.2\"\n\n name: 🐍 3.11 • CMake ${{ matrix.cmake }} • ${{ matrix.runs-on }}\n runs-on: ${{ matrix.runs-on }}\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python 3.11\n uses: actions/setup-python@v6\n with:\n python-version: 3.11\n\n - name: Install uv\n uses: astral-sh/setup-uv@v7\n\n - name: Prepare env\n run: uv pip install --python=python --system -r tests/requirements.txt\n\n # An action for adding a specific version of CMake:\n # https://github.com/jwlawson/actions-setup-cmake\n - name: Setup CMake ${{ matrix.cmake }}\n uses: jwlawson/actions-setup-cmake@v2.1\n with:\n cmake-version: ${{ matrix.cmake }}\n\n # These steps use a directory with a space in it intentionally\n - name: Configure\n shell: bash\n run: cmake -S. -B\"build dir\" -DPYBIND11_WERROR=ON -DDOWNLOAD_CATCH=ON\n\n # Only build and test if this was manually triggered in the GitHub UI\n - name: Build\n working-directory: build dir\n if: github.event_name == 'workflow_dispatch'\n run: cmake --build . --config Release\n\n - name: Test\n working-directory: build dir\n if: github.event_name == 'workflow_dispatch'\n run: cmake --build . --config Release --target check\n" }, { "path": ".github/workflows/docs-link.yml", "content": "name: Read the Docs PR preview\n\non:\n pull_request_target:\n types:\n - opened\n - synchronize\n\npermissions:\n contents: read\n pull-requests: write\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n\njobs:\n documentation-links:\n runs-on: ubuntu-latest\n if: github.event.repository.fork == false\n steps:\n - uses: actions/checkout@v6\n\n - name: Check for docs changes\n id: docs_changes\n run: |\n # Fetch the PR head\n git fetch origin pull/${{ github.event.pull_request.number }}/head:pr-head\n\n # Show diff between base (current checkout) and PR head\n if git diff --name-only HEAD pr-head | grep -q '^docs/'; then\n echo \"docs_changed=true\" >> \"$GITHUB_OUTPUT\"\n else\n echo \"docs_changed=false\" >> \"$GITHUB_OUTPUT\"\n fi\n\n - uses: readthedocs/actions/preview@v1\n if: steps.docs_changes.outputs.docs_changed == 'true'\n with:\n project-slug: \"pybind11\"\n single-version: \"true\"\n" }, { "path": ".github/workflows/format.yml", "content": "# This is a format job. Pre-commit has a first-party GitHub action, so we use\n# that: https://github.com/pre-commit/action\n\nname: Format\n\non:\n workflow_dispatch:\n pull_request:\n push:\n branches:\n - master\n - stable\n - \"v*\"\n\npermissions:\n contents: read\n\nenv:\n FORCE_COLOR: 3\n # For cmake:\n VERBOSE: 1\n\njobs:\n pre-commit:\n name: Format\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-python@v6\n with:\n python-version: \"3.x\"\n - name: Add matchers\n run: echo \"::add-matcher::$GITHUB_WORKSPACE/.github/matchers/pylint.json\"\n - uses: pre-commit/action@v3.0.1\n\n clang-tidy:\n # When making changes here, please also review the \"Clang-Tidy\" section\n # in .github/CONTRIBUTING.md and update as needed.\n name: Clang-Tidy\n runs-on: ubuntu-latest\n container: silkeh/clang:20\n steps:\n - uses: actions/checkout@v6\n\n - name: Install requirements\n run: apt-get update && apt-get install -y git python3-dev python3-pytest ninja-build\n\n - name: Configure\n run: cmake --preset tidy\n - name: Build\n run: cmake --build --preset tidy\n\n - name: Embedded\n run: cmake --build --preset tidy -t cpptest\n" }, { "path": ".github/workflows/labeler.yml", "content": "name: Labeler\non:\n pull_request_target:\n types: [closed]\n\npermissions: {}\n\njobs:\n label:\n name: Labeler\n runs-on: ubuntu-latest\n permissions:\n contents: read\n pull-requests: write\n steps:\n\n - uses: actions/labeler@v6\n if: >\n github.event.pull_request.merged == true &&\n !startsWith(github.event.pull_request.title, 'chore(deps):') &&\n !startsWith(github.event.pull_request.title, 'ci(fix):') &&\n !startsWith(github.event.pull_request.title, 'docs(changelog):')\n with:\n repo-token: ${{ secrets.GITHUB_TOKEN }}\n configuration-path: .github/labeler_merged.yml\n" }, { "path": ".github/workflows/nightlies.yml", "content": "name: Upload nightly wheels to Anaconda Cloud\n\non:\n # Run daily at 2:34 UTC to upload nightly wheels to Anaconda Cloud\n schedule:\n - cron: \"34 2 * * *\"\n # Run on demand with workflow dispatch\n workflow_dispatch:\n\npermissions:\n actions: read\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n\njobs:\n build_wheel:\n name: Build and upload wheel\n if: github.repository_owner == 'pybind'\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n with:\n fetch-depth: 0\n\n - name: Install uv\n uses: astral-sh/setup-uv@v7\n\n - name: Build SDist and wheels\n run: |\n uv tool install nox\n nox -s build\n nox -s build_global\n\n - uses: actions/upload-artifact@v7\n with:\n name: Packages\n path: dist/*\n\n upload_nightly_wheels:\n name: Upload nightly wheels to Anaconda Cloud\n if: github.repository_owner == 'pybind'\n needs: [build_wheel]\n runs-on: ubuntu-latest\n steps:\n - uses: actions/download-artifact@v8\n with:\n name: Packages\n path: dist\n\n - name: List wheel to be deployed\n run: ls -lha dist/*.whl\n\n - name: Upload wheel to Anaconda Cloud as nightly\n uses: scientific-python/upload-nightly-action@5748273c71e2d8d3a61f3a11a16421c8954f9ecf # 0.6.3\n with:\n artifacts_path: dist\n anaconda_nightly_upload_token: ${{ secrets.ANACONDA_ORG_UPLOAD_TOKEN }}\n" }, { "path": ".github/workflows/pip.yml", "content": "name: Pip\n\non:\n workflow_dispatch:\n pull_request:\n push:\n branches:\n - master\n - stable\n - v*\n release:\n types:\n - published\n\npermissions:\n contents: read\n\njobs:\n # This builds the sdists and wheels and makes sure the files are exactly as\n # expected.\n test-packaging:\n name: 🐍 3.8 • 📦 tests • windows-latest\n runs-on: windows-latest\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup 🐍 3.8\n uses: actions/setup-python@v6\n with:\n python-version: 3.8\n\n - name: Install uv\n uses: astral-sh/setup-uv@v7\n\n - name: Prepare env\n run: uv pip install --system -r tests/requirements.txt\n\n - name: Python Packaging tests\n run: pytest tests/extra_python_package/\n\n\n # This runs the packaging tests and also builds and saves the packages as\n # artifacts.\n packaging:\n name: 🐍 3.8 • 📦 & 📦 tests • ubuntu-latest\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup 🐍 3.8\n uses: actions/setup-python@v6\n with:\n python-version: 3.8\n\n - name: Install uv\n uses: astral-sh/setup-uv@v7\n\n - name: Prepare env\n run: uv pip install --system -r tests/requirements.txt twine nox\n\n - name: Python Packaging tests\n run: pytest tests/extra_python_package/\n\n - name: Build SDist and wheels\n run: |\n nox -s build\n nox -s build_global\n\n - name: Check metadata\n run: twine check dist/*\n\n - name: Save standard package\n uses: actions/upload-artifact@v7\n with:\n name: standard\n path: dist/pybind11-*\n\n - name: Save global package\n uses: actions/upload-artifact@v7\n with:\n name: global\n path: dist/*global-*\n\n\n\n # When a GitHub release is made, upload the artifacts to PyPI\n upload:\n name: Upload to PyPI\n runs-on: ubuntu-latest\n if: github.event_name == 'release' && github.event.action == 'published'\n needs: [packaging]\n environment:\n name: pypi\n url: https://pypi.org/p/pybind11\n permissions:\n id-token: write\n attestations: write\n\n steps:\n # Downloads all to directories matching the artifact names\n - uses: actions/download-artifact@v8\n\n - name: Generate artifact attestation for sdist and wheel\n uses: actions/attest-build-provenance@v4\n with:\n subject-path: \"*/pybind11*\"\n\n - name: Publish standard package\n uses: pypa/gh-action-pypi-publish@release/v1\n with:\n packages-dir: standard/\n\n - name: Publish global package\n uses: pypa/gh-action-pypi-publish@release/v1\n with:\n packages-dir: global/\n" }, { "path": ".github/workflows/reusable-standard.yml", "content": "name: Reusable Standard Test\n\non:\n workflow_call:\n inputs:\n python-version:\n required: true\n type: string\n cmake-args:\n required: false\n type: string\n default: ''\n runs-on:\n required: true\n type: string\n\nenv:\n PYTHONDEVMODE: 1\n PIP_BREAK_SYSTEM_PACKAGES: 1\n PIP_ONLY_BINARY: numpy\n FORCE_COLOR: 3\n PYTEST_TIMEOUT: 300\n # For cmake:\n VERBOSE: 1\n CMAKE_COLOR_DIAGNOSTICS: 1\n\njobs:\n standard:\n name: 🧪\n runs-on: ${{ inputs.runs-on }}\n timeout-minutes: 90\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python ${{ inputs.python-version }}\n uses: actions/setup-python@v6\n with:\n python-version: ${{ inputs.python-version }}\n allow-prereleases: true\n # Python 3.13.4 broken on Windows\n check-latest: >-\n ${{ inputs.python-version == '3.13' && runner.os == 'Windows' }}\n\n - name: Setup Boost (Linux)\n if: runner.os == 'Linux'\n run: sudo apt-get update && sudo apt-get install -y libboost-dev\n\n - name: Setup Boost (macOS)\n if: runner.os == 'macOS'\n run: brew install boost\n\n - name: Install uv\n uses: astral-sh/setup-uv@v7\n with:\n enable-cache: true\n\n - name: Prepare env\n run: uv pip install --python=python --system -r tests/requirements.txt\n\n - name: Setup annotations on Linux\n if: runner.os == 'Linux'\n run: uv pip install --python=python --system pytest-github-actions-annotate-failures\n\n # TODO Resolve Windows Ninja shared object issue on Python 3.8+\n - name: Use Ninja except on Windows\n if: runner.os != 'Windows'\n run: echo \"CMAKE_GENERATOR=Ninja\" >> \"$GITHUB_ENV\"\n\n - name: Configure\n run: >\n cmake -S. -Bbuild -Werror=dev\n -DPYBIND11_WERROR=ON\n -DPYBIND11_PYTEST_ARGS=-v\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n ${{ inputs.cmake-args }}\n\n - name: Build\n run: cmake --build build\n\n - name: Python tests\n run: cmake --build build --target pytest\n\n - name: C++ tests\n timeout-minutes: 3\n run: cmake --build build --target cpptest\n\n - name: Interface test\n run: cmake --build build --target test_cmake_build\n\n - name: Visibility test\n run: cmake --build build --target test_cross_module_rtti\n\n - name: Setuptools helpers test\n run: |\n uv pip install --python=python --system setuptools\n pytest tests/extra_setuptools\n" }, { "path": ".github/workflows/tests-cibw.yml", "content": "name: CIBW\n\non:\n workflow_dispatch:\n pull_request:\n branches:\n - master\n - stable\n - v*\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n\njobs:\n build-wasm-emscripten:\n name: Pyodide wheel\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n with:\n submodules: true\n fetch-depth: 0\n\n - uses: pypa/cibuildwheel@v3.3\n env:\n PYODIDE_BUILD_EXPORTS: whole_archive\n with:\n package-dir: tests\n only: cp312-pyodide_wasm32\n\n build-ios:\n name: iOS wheel ${{ matrix.runs-on }}\n runs-on: ${{ matrix.runs-on }}\n strategy:\n fail-fast: false\n matrix:\n runs-on: [macos-14, macos-15-intel]\n steps:\n - uses: actions/checkout@v6\n with:\n submodules: true\n fetch-depth: 0\n\n # We have to uninstall first because GH is now using a local tap to build cmake<4, iOS needs cmake>=4\n - run: brew uninstall cmake && brew install cmake\n\n - uses: pypa/cibuildwheel@v3.3\n env:\n CIBW_PLATFORM: ios\n CIBW_SKIP: cp314-* # https://github.com/pypa/cibuildwheel/issues/2494\n with:\n package-dir: tests\n\n build-android:\n name: Android wheel ${{ matrix.runs-on }}\n runs-on: ${{ matrix.runs-on }}\n strategy:\n fail-fast: false\n matrix:\n runs-on: [macos-latest, macos-15-intel, ubuntu-latest]\n steps:\n - uses: actions/checkout@v6\n with:\n submodules: true\n fetch-depth: 0\n\n # GitHub Actions can't currently run the Android emulator on macOS.\n - name: Skip Android tests on macOS\n if: contains(matrix.runs-on, 'macos')\n run: echo \"CIBW_TEST_COMMAND=\" >> \"$GITHUB_ENV\"\n\n - uses: pypa/cibuildwheel@v3.3\n env:\n CIBW_PLATFORM: android\n with:\n package-dir: tests\n" }, { "path": ".github/workflows/upstream.yml", "content": "name: Upstream\n\non:\n workflow_dispatch:\n pull_request:\n\npermissions:\n contents: read\n\nconcurrency:\n group: upstream-${{ github.ref }}\n cancel-in-progress: true\n\nenv:\n PIP_BREAK_SYSTEM_PACKAGES: 1\n # For cmake:\n VERBOSE: 1\n\njobs:\n standard:\n name: \"🐍 3.13 latest • ubuntu-latest • x64\"\n runs-on: ubuntu-latest\n # Only runs when the 'python dev' label is selected\n if: \"contains(github.event.pull_request.labels.*.name, 'python dev')\"\n\n steps:\n - uses: actions/checkout@v6\n\n - name: Setup Python 3.13\n uses: actions/setup-python@v6\n with:\n python-version: \"3.13\"\n allow-prereleases: true\n\n - name: Setup Boost\n run: sudo apt-get install libboost-dev\n\n - name: Update CMake\n uses: jwlawson/actions-setup-cmake@v2.1\n\n - name: Run pip installs\n run: |\n python -m pip install --upgrade pip\n python -m pip install -r tests/requirements.txt\n\n - name: Show platform info\n run: |\n python -m platform\n cmake --version\n pip list\n\n # First build - C++11 mode and inplace\n - name: Configure C++11\n run: >\n cmake -S . -B build11\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=11\n -DCMAKE_BUILD_TYPE=Debug\n\n - name: Build C++11\n run: cmake --build build11 -j 2\n\n - name: Python tests C++11\n run: cmake --build build11 --target pytest -j 2\n\n - name: C++11 tests\n timeout-minutes: 3\n run: cmake --build build11 --target cpptest -j 2\n\n - name: Interface test C++11\n run: cmake --build build11 --target test_cmake_build\n\n # Second build - C++17 mode and in a build directory\n - name: Configure C++17\n run: >\n cmake -S . -B build17\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=17\n\n - name: Build C++17\n run: cmake --build build17 -j 2\n\n - name: Python tests C++17\n run: cmake --build build17 --target pytest\n\n - name: C++17 tests\n timeout-minutes: 3\n run: cmake --build build17 --target cpptest\n\n # Third build - C++17 mode with unstable ABI\n - name: Configure (unstable ABI)\n run: >\n cmake -S . -B build17max\n -DPYBIND11_WERROR=ON\n -DDOWNLOAD_CATCH=ON\n -DDOWNLOAD_EIGEN=ON\n -DCMAKE_CXX_STANDARD=17\n -DPYBIND11_INTERNALS_VERSION=10000000\n\n - name: Build (unstable ABI)\n run: cmake --build build17max -j 2\n\n - name: Python tests (unstable ABI)\n run: cmake --build build17max --target pytest\n\n - name: Interface test (unstable ABI)\n run: cmake --build build17max --target test_cmake_build\n\n # This makes sure the setup_helpers module can build packages using\n # setuptools\n - name: Setuptools helpers test\n run: |\n pip install setuptools\n pytest tests/extra_setuptools\n" }, { "path": ".gitignore", "content": "CMakeCache.txt\nCMakeFiles\nMakefile\ncmake_install.cmake\ncmake_uninstall.cmake\n.DS_Store\n*.so\n*.pyd\n*.dll\n*.sln\n*.sdf\n*.opensdf\n*.vcxproj\n*.vcxproj.user\n*.filters\nexample.dir\nWin32\nx64\nRelease\nDebug\n.vs\nCTestTestfile.cmake\nTesting\nautogen\nMANIFEST\n/.ninja_*\n/*.ninja\n/docs/.build\n__pycache__/\n*.py[co]\n*.egg-info\n*~\n.*.swp\n.DS_Store\n/dist\n/*build*\n.cache/\nsosize-*.txt\npybind11Config*.cmake\npybind11Targets.cmake\n/*env*\n/.vscode\n/pybind11/include/*\n/pybind11/share/*\n/docs/_build/*\n.ipynb_checkpoints/\ntests/main.cpp\nCMakeUserPresents.json\n\n/Python\n/tmp*\n.ruby-version\n.*cache*/\n*.lock\n" }, { "path": ".pre-commit-config.yaml", "content": "# To use:\n#\n# pre-commit run -a\n#\n# Or:\n#\n# pre-commit install # (runs every time you commit in git)\n#\n# To update this file:\n#\n# pre-commit autoupdate\n#\n# See https://github.com/pre-commit/pre-commit\n\n\nci:\n autoupdate_commit_msg: \"chore(deps): update pre-commit hooks\"\n autofix_commit_msg: \"style: pre-commit fixes\"\n autoupdate_schedule: monthly\n\n# third-party content\nexclude: ^tools/JoinPaths.cmake$\n\nrepos:\n\n# Clang format the codebase automatically\n- repo: https://github.com/pre-commit/mirrors-clang-format\n rev: \"v21.1.8\"\n hooks:\n - id: clang-format\n types_or: [c++, c, cuda]\n\n# Ruff, the Python auto-correcting linter/formatter written in Rust\n- repo: https://github.com/astral-sh/ruff-pre-commit\n rev: v0.14.14\n hooks:\n - id: ruff-check\n args: [\"--fix\", \"--show-fixes\"]\n - id: ruff-format\n\n# Check static types with mypy\n- repo: https://github.com/pre-commit/mirrors-mypy\n rev: \"v1.19.1\"\n hooks:\n - id: mypy\n args: []\n exclude: ^(tests|docs)/\n additional_dependencies:\n - markdown-it-py\n - nox\n - rich\n - types-setuptools\n\n# CMake formatting\n- repo: https://github.com/cheshirekow/cmake-format-precommit\n rev: \"v0.6.13\"\n hooks:\n - id: cmake-format\n additional_dependencies: [pyyaml]\n types: [file]\n files: (\\.cmake|CMakeLists.txt)(.in)?$\n\n# Standard hooks\n- repo: https://github.com/pre-commit/pre-commit-hooks\n rev: \"v6.0.0\"\n hooks:\n - id: check-added-large-files\n - id: check-case-conflict\n - id: check-docstring-first\n - id: check-merge-conflict\n - id: check-symlinks\n - id: check-toml\n - id: check-yaml\n - id: debug-statements\n - id: end-of-file-fixer\n - id: mixed-line-ending\n - id: requirements-txt-fixer\n - id: trailing-whitespace\n exclude: \\.patch?$\n\n# Also code format the docs\n- repo: https://github.com/adamchainz/blacken-docs\n rev: \"1.20.0\"\n hooks:\n - id: blacken-docs\n additional_dependencies:\n - black==23.*\n\n# Changes tabs to spaces\n- repo: https://github.com/Lucas-C/pre-commit-hooks\n rev: \"v1.5.6\"\n hooks:\n - id: remove-tabs\n exclude: (^docs/.*|\\.patch)?$\n\n# Avoid directional quotes\n- repo: https://github.com/sirosen/texthooks\n rev: \"0.7.1\"\n hooks:\n - id: fix-ligatures\n - id: fix-smartquotes\n\n# Checking for common mistakes\n- repo: https://github.com/pre-commit/pygrep-hooks\n rev: \"v1.10.0\"\n hooks:\n - id: rst-backticks\n - id: rst-directive-colons\n - id: rst-inline-touching-normal\n\n# Check for spelling\n# Use tools/codespell_ignore_lines_from_errors.py\n# to rebuild .codespell-ignore-lines\n- repo: https://github.com/codespell-project/codespell\n rev: \"v2.4.1\"\n hooks:\n - id: codespell\n exclude: \"(.supp|^pyproject.toml)$\"\n args: [\"-x.codespell-ignore-lines\", \"-Lccompiler,intstruct\"]\n\n# Also check spelling\n# Use mirror because pre-commit autoupdate confuses tags in the upstream repo.\n# See https://github.com/crate-ci/typos/issues/390\n- repo: https://github.com/adhtruong/mirrors-typos\n rev: \"v1.42.3\"\n hooks:\n - id: typos\n args: []\n\n# Check for common shell mistakes\n- repo: https://github.com/shellcheck-py/shellcheck-py\n rev: \"v0.11.0.1\"\n hooks:\n - id: shellcheck\n\n# Disallow some common capitalization mistakes\n- repo: local\n hooks:\n - id: disallow-caps\n name: Disallow improper capitalization\n language: pygrep\n entry: PyBind|\\bNumpy\\b|Cmake|CCache|PyTest\n exclude: ^\\.pre-commit-config.yaml$\n\n# PyLint has native support - not always usable, but works for us\n- repo: https://github.com/PyCQA/pylint\n rev: \"v4.0.4\"\n hooks:\n - id: pylint\n files: ^pybind11\n\n# Check schemas on some of our YAML files\n- repo: https://github.com/python-jsonschema/check-jsonschema\n rev: 0.36.1\n hooks:\n - id: check-readthedocs\n - id: check-github-workflows\n - id: check-dependabot\n" }, { "path": ".readthedocs.yml", "content": "# https://blog.readthedocs.com/migrate-configuration-v2/\n\nversion: 2\n\nbuild:\n os: ubuntu-22.04\n apt_packages:\n - librsvg2-bin\n tools:\n python: \"3.11\"\n\nsphinx:\n configuration: docs/conf.py\n\npython:\n install:\n - requirements: docs/requirements.txt\n\nformats:\n - pdf\n" }, { "path": "CMakeLists.txt", "content": "# CMakeLists.txt -- Build system for the pybind11 modules\n#\n# Copyright (c) 2015 Wenzel Jakob \n#\n# All rights reserved. Use of this source code is governed by a\n# BSD-style license that can be found in the LICENSE file.\n\n# Propagate this policy (FindPythonInterp removal) so it can be detected later\nif(NOT CMAKE_VERSION VERSION_LESS \"3.27\")\n cmake_policy(GET CMP0148 _pybind11_cmp0148)\nendif()\n\ncmake_minimum_required(VERSION 3.15...4.2)\n\nif(_pybind11_cmp0148)\n cmake_policy(SET CMP0148 ${_pybind11_cmp0148})\n unset(_pybind11_cmp0148)\nendif()\n\n# Avoid infinite recursion if tests include this as a subdirectory\ninclude_guard(GLOBAL)\n\n# Extract project version from source\nfile(STRINGS \"${CMAKE_CURRENT_SOURCE_DIR}/include/pybind11/detail/common.h\"\n pybind11_version_defines REGEX \"#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) \")\n\nforeach(ver ${pybind11_version_defines})\n if(ver MATCHES [[#define PYBIND11_VERSION_(MAJOR|MINOR|PATCH) +([^ ]+)$]])\n set(PYBIND11_VERSION_${CMAKE_MATCH_1} \"${CMAKE_MATCH_2}\")\n endif()\nendforeach()\n\nif(PYBIND11_VERSION_PATCH MATCHES [[\\.([a-zA-Z0-9]+)$]])\n set(pybind11_VERSION_TYPE \"${CMAKE_MATCH_1}\")\nendif()\nstring(REGEX MATCH \"^[0-9]+\" PYBIND11_VERSION_PATCH \"${PYBIND11_VERSION_PATCH}\")\n\nproject(\n pybind11\n LANGUAGES CXX\n VERSION \"${PYBIND11_VERSION_MAJOR}.${PYBIND11_VERSION_MINOR}.${PYBIND11_VERSION_PATCH}\")\n\n# Standard includes\ninclude(GNUInstallDirs)\ninclude(CMakePackageConfigHelpers)\ninclude(CMakeDependentOption)\n\nif(NOT pybind11_FIND_QUIETLY)\n message(STATUS \"pybind11 v${pybind11_VERSION} ${pybind11_VERSION_TYPE}\")\nendif()\n\n# Check if pybind11 is being used directly or via add_subdirectory\nif(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)\n ### Warn if not an out-of-source builds\n if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)\n set(lines\n \"You are building in-place. If that is not what you intended to \"\n \"do, you can clean the source directory with:\\n\"\n \"rm -r CMakeCache.txt CMakeFiles/ cmake_uninstall.cmake pybind11Config.cmake \"\n \"pybind11ConfigVersion.cmake tests/CMakeFiles/\\n\")\n message(AUTHOR_WARNING ${lines})\n endif()\n\n set(PYBIND11_MASTER_PROJECT ON)\n\n message(STATUS \"CMake ${CMAKE_VERSION}\")\n\n if(DEFINED SKBUILD AND DEFINED ENV{PYBIND11_GLOBAL_SDIST})\n message(\n FATAL_ERROR\n \"PYBIND11_GLOBAL_SDIST is not supported, use nox -s build_global or a pybind11-global SDist instead.\"\n )\n endif()\n\n if(CMAKE_CXX_STANDARD)\n set(CMAKE_CXX_EXTENSIONS OFF)\n set(CMAKE_CXX_STANDARD_REQUIRED ON)\n endif()\n\n set(pybind11_system \"\")\n\n set_property(GLOBAL PROPERTY USE_FOLDERS ON)\n if(CMAKE_VERSION VERSION_LESS \"3.18\")\n set(_pybind11_findpython_default OFF)\n else()\n set(_pybind11_findpython_default ON)\n endif()\nelse()\n set(PYBIND11_MASTER_PROJECT OFF)\n set(pybind11_system SYSTEM)\n set(_pybind11_findpython_default COMPAT)\nendif()\n\n# Options\noption(PYBIND11_INSTALL \"Install pybind11 header files?\" ${PYBIND11_MASTER_PROJECT})\noption(PYBIND11_TEST \"Build pybind11 test suite?\" ${PYBIND11_MASTER_PROJECT})\noption(PYBIND11_NOPYTHON \"Disable search for Python\" OFF)\noption(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION\n \"To enforce that a handle_type_name<> specialization exists\" OFF)\noption(PYBIND11_SIMPLE_GIL_MANAGEMENT\n \"Use simpler GIL management logic that does not support disassociation\" OFF)\nset(PYBIND11_INTERNALS_VERSION\n \"\"\n CACHE STRING \"Override the ABI version, may be used to enable the unstable ABI.\")\noption(PYBIND11_USE_CROSSCOMPILING \"Respect CMAKE_CROSSCOMPILING\" OFF)\n\nif(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION)\n add_compile_definitions(PYBIND11_DISABLE_HANDLE_TYPE_NAME_DEFAULT_IMPLEMENTATION)\nendif()\nif(PYBIND11_SIMPLE_GIL_MANAGEMENT)\n add_compile_definitions(PYBIND11_SIMPLE_GIL_MANAGEMENT)\nendif()\n\ncmake_dependent_option(\n USE_PYTHON_INCLUDE_DIR\n \"Install pybind11 headers in Python include directory instead of default installation prefix\"\n OFF \"PYBIND11_INSTALL\" OFF)\n\nset(PYBIND11_FINDPYTHON\n ${_pybind11_findpython_default}\n CACHE STRING \"Force new FindPython - NEW, OLD, COMPAT\")\n\nif(PYBIND11_MASTER_PROJECT)\n\n # Allow PYTHON_EXECUTABLE if in FINDPYTHON mode and building pybind11's tests\n # (makes transition easier while we support both modes).\n if(PYBIND11_FINDPYTHON\n AND DEFINED PYTHON_EXECUTABLE\n AND NOT DEFINED Python_EXECUTABLE)\n set(Python_EXECUTABLE \"${PYTHON_EXECUTABLE}\")\n endif()\n\n # This is a shortcut that is primarily for the venv cmake preset,\n # but can be used to quickly setup tests manually, too\n set(PYBIND11_CREATE_WITH_UV\n \"\"\n CACHE STRING \"Create a virtualenv if it doesn't exist\")\n\n if(NOT PYBIND11_CREATE_WITH_UV STREQUAL \"\")\n set(Python_ROOT_DIR \"${CMAKE_CURRENT_BINARY_DIR}/.venv\")\n if(EXISTS \"${Python_ROOT_DIR}\")\n if(EXISTS \"${CMAKE_BINARY_DIR}/CMakeCache.txt\")\n message(STATUS \"Using existing venv at ${Python_ROOT_DIR}, remove or --fresh to recreate\")\n else()\n # --fresh used to remove the cache\n file(REMOVE_RECURSE \"${CMAKE_CURRENT_BINARY_DIR}/.venv\")\n endif()\n endif()\n if(NOT EXISTS \"${Python_ROOT_DIR}\")\n find_program(UV uv REQUIRED)\n # CMake 3.19+ would be able to use COMMAND_ERROR_IS_FATAL\n message(\n STATUS \"Creating venv with ${UV} venv -p ${PYBIND11_CREATE_WITH_UV} '${Python_ROOT_DIR}'\")\n execute_process(COMMAND ${UV} venv -p ${PYBIND11_CREATE_WITH_UV} \"${Python_ROOT_DIR}\"\n RESULT_VARIABLE _venv_result)\n if(_venv_result AND NOT _venv_result EQUAL 0)\n message(FATAL_ERROR \"uv venv failed with '${_venv_result}'\")\n endif()\n message(\n STATUS\n \"Installing deps with ${UV} pip install -p '${Python_ROOT_DIR}' -r tests/requirements.txt\"\n )\n execute_process(\n COMMAND ${UV} pip install -p \"${Python_ROOT_DIR}\" -r\n \"${CMAKE_CURRENT_SOURCE_DIR}/tests/requirements.txt\" RESULT_VARIABLE _pip_result)\n if(_pip_result AND NOT _pip_result EQUAL 0)\n message(FATAL_ERROR \"uv pip install failed with '${_pip_result}'\")\n endif()\n endif()\n else()\n if(NOT DEFINED Python3_EXECUTABLE\n AND NOT DEFINED Python_EXECUTABLE\n AND NOT DEFINED Python_ROOT_DIR\n AND NOT DEFINED ENV{VIRTUALENV}\n AND EXISTS \"${CMAKE_CURRENT_SOURCE_DIR}/.venv\")\n message(STATUS \"Autodetecting Python in virtual environment\")\n set(Python_ROOT_DIR \"${CMAKE_CURRENT_SOURCE_DIR}/.venv\")\n endif()\n endif()\nendif()\n\nset(PYBIND11_HEADERS\n include/pybind11/detail/argument_vector.h\n include/pybind11/detail/class.h\n include/pybind11/detail/common.h\n include/pybind11/detail/cpp_conduit.h\n include/pybind11/detail/descr.h\n include/pybind11/detail/dynamic_raw_ptr_cast_if_possible.h\n include/pybind11/detail/exception_translation.h\n include/pybind11/detail/function_record_pyobject.h\n include/pybind11/detail/function_ref.h\n include/pybind11/detail/holder_caster_foreign_helpers.h\n include/pybind11/detail/init.h\n include/pybind11/detail/internals.h\n include/pybind11/detail/native_enum_data.h\n include/pybind11/detail/pybind11_namespace_macros.h\n include/pybind11/detail/struct_smart_holder.h\n include/pybind11/detail/type_caster_base.h\n include/pybind11/detail/typeid.h\n include/pybind11/detail/using_smart_holder.h\n include/pybind11/detail/value_and_holder.h\n include/pybind11/attr.h\n include/pybind11/buffer_info.h\n include/pybind11/cast.h\n include/pybind11/chrono.h\n include/pybind11/common.h\n include/pybind11/complex.h\n include/pybind11/conduit/pybind11_conduit_v1.h\n include/pybind11/conduit/pybind11_platform_abi_id.h\n include/pybind11/conduit/wrap_include_python_h.h\n include/pybind11/critical_section.h\n include/pybind11/options.h\n include/pybind11/eigen.h\n include/pybind11/eigen/common.h\n include/pybind11/eigen/matrix.h\n include/pybind11/eigen/tensor.h\n include/pybind11/embed.h\n include/pybind11/eval.h\n include/pybind11/gil.h\n include/pybind11/gil_safe_call_once.h\n include/pybind11/gil_simple.h\n include/pybind11/iostream.h\n include/pybind11/functional.h\n include/pybind11/native_enum.h\n include/pybind11/numpy.h\n include/pybind11/operators.h\n include/pybind11/pybind11.h\n include/pybind11/pytypes.h\n include/pybind11/subinterpreter.h\n include/pybind11/stl.h\n include/pybind11/stl_bind.h\n include/pybind11/stl/filesystem.h\n include/pybind11/trampoline_self_life_support.h\n include/pybind11/type_caster_pyobject_ptr.h\n include/pybind11/typing.h\n include/pybind11/warnings.h)\n\n# Compare with grep and warn if mismatched\nif(PYBIND11_MASTER_PROJECT)\n file(\n GLOB_RECURSE _pybind11_header_check\n LIST_DIRECTORIES false\n RELATIVE \"${CMAKE_CURRENT_SOURCE_DIR}\"\n CONFIGURE_DEPENDS \"include/pybind11/*.h\")\n set(_pybind11_here_only ${PYBIND11_HEADERS})\n set(_pybind11_disk_only ${_pybind11_header_check})\n list(REMOVE_ITEM _pybind11_here_only ${_pybind11_header_check})\n list(REMOVE_ITEM _pybind11_disk_only ${PYBIND11_HEADERS})\n if(_pybind11_here_only)\n message(AUTHOR_WARNING \"PYBIND11_HEADERS has extra files:\" ${_pybind11_here_only})\n endif()\n if(_pybind11_disk_only)\n message(AUTHOR_WARNING \"PYBIND11_HEADERS is missing files:\" ${_pybind11_disk_only})\n endif()\nendif()\n\nlist(TRANSFORM PYBIND11_HEADERS PREPEND \"${CMAKE_CURRENT_SOURCE_DIR}/\")\n\n# Cache variable so this can be used in parent projects\nset(pybind11_INCLUDE_DIR\n \"${CMAKE_CURRENT_LIST_DIR}/include\"\n CACHE INTERNAL \"Directory where pybind11 headers are located\")\n\n# Backward compatible variable for add_subdirectory mode\nif(NOT PYBIND11_MASTER_PROJECT)\n set(PYBIND11_INCLUDE_DIR\n \"${pybind11_INCLUDE_DIR}\"\n CACHE INTERNAL \"\")\nendif()\n\n# Note: when creating targets, you cannot use if statements at configure time -\n# you need generator expressions, because those will be placed in the target file.\n# You can also place ifs *in* the Config.in, but not here.\n\n# This section builds targets, but does *not* touch Python\n# Non-IMPORT targets cannot be defined twice\nif(NOT TARGET pybind11_headers)\n # Build the headers-only target (no Python included):\n # (long name used here to keep this from clashing in subdirectory mode)\n add_library(pybind11_headers INTERFACE)\n add_library(pybind11::pybind11_headers ALIAS pybind11_headers) # to match exported target\n add_library(pybind11::headers ALIAS pybind11_headers) # easier to use/remember\n\n target_include_directories(\n pybind11_headers ${pybind11_system} INTERFACE $\n $)\n\n target_compile_features(pybind11_headers INTERFACE cxx_inheriting_constructors cxx_user_literals\n cxx_right_angle_brackets)\n if(NOT \"${PYBIND11_INTERNALS_VERSION}\" STREQUAL \"\")\n target_compile_definitions(\n pybind11_headers INTERFACE \"PYBIND11_INTERNALS_VERSION=${PYBIND11_INTERNALS_VERSION}\")\n endif()\nelse()\n # It is invalid to install a target twice, too.\n set(PYBIND11_INSTALL OFF)\nendif()\n\ninclude(\"${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11Common.cmake\")\n# https://github.com/jtojnar/cmake-snips/#concatenating-paths-when-building-pkg-config-files\n# TODO: cmake 3.20 adds the cmake_path() function, which obsoletes this snippet\ninclude(\"${CMAKE_CURRENT_SOURCE_DIR}/tools/JoinPaths.cmake\")\n\n# Relative directory setting\nif(USE_PYTHON_INCLUDE_DIR AND DEFINED Python_INCLUDE_DIRS)\n file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${Python_INCLUDE_DIRS})\nelseif(USE_PYTHON_INCLUDE_DIR AND DEFINED PYTHON_INCLUDE_DIR)\n file(RELATIVE_PATH CMAKE_INSTALL_INCLUDEDIR ${CMAKE_INSTALL_PREFIX} ${PYTHON_INCLUDE_DIRS})\nendif()\n\nif(PYBIND11_INSTALL)\n if(DEFINED SKBUILD_PROJECT_NAME AND SKBUILD_PROJECT_NAME STREQUAL \"pybind11_global\")\n install(DIRECTORY ${pybind11_INCLUDE_DIR}/pybind11 DESTINATION \"${SKBUILD_HEADERS_DIR}\")\n endif()\n install(DIRECTORY ${pybind11_INCLUDE_DIR}/pybind11 DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})\n set(PYBIND11_CMAKECONFIG_INSTALL_DIR\n \"${CMAKE_INSTALL_DATAROOTDIR}/cmake/${PROJECT_NAME}\"\n CACHE STRING \"install path for pybind11Config.cmake\")\n\n if(IS_ABSOLUTE \"${CMAKE_INSTALL_INCLUDEDIR}\")\n set(pybind11_INCLUDEDIR \"${CMAKE_INSTALL_FULL_INCLUDEDIR}\")\n else()\n set(pybind11_INCLUDEDIR \"\\$\\{PACKAGE_PREFIX_DIR\\}/${CMAKE_INSTALL_INCLUDEDIR}\")\n endif()\n\n configure_package_config_file(\n tools/${PROJECT_NAME}Config.cmake.in \"${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake\"\n INSTALL_DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})\n\n # CMake natively supports header-only libraries\n write_basic_package_version_file(\n ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake\n VERSION ${PROJECT_VERSION}\n COMPATIBILITY AnyNewerVersion ARCH_INDEPENDENT)\n\n install(\n FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Config.cmake\n ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake\n tools/FindPythonLibsNew.cmake\n tools/pybind11Common.cmake\n tools/pybind11Tools.cmake\n tools/pybind11NewTools.cmake\n tools/pybind11GuessPythonExtSuffix.cmake\n DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})\n\n if(NOT PYBIND11_EXPORT_NAME)\n set(PYBIND11_EXPORT_NAME \"${PROJECT_NAME}Targets\")\n endif()\n\n install(TARGETS pybind11_headers EXPORT \"${PYBIND11_EXPORT_NAME}\")\n\n install(\n EXPORT \"${PYBIND11_EXPORT_NAME}\"\n NAMESPACE \"pybind11::\"\n DESTINATION ${PYBIND11_CMAKECONFIG_INSTALL_DIR})\n\n # pkg-config support\n if(NOT prefix_for_pc_file)\n if(IS_ABSOLUTE \"${CMAKE_INSTALL_DATAROOTDIR}\")\n set(prefix_for_pc_file \"${CMAKE_INSTALL_PREFIX}\")\n else()\n set(pc_datarootdir \"${CMAKE_INSTALL_DATAROOTDIR}\")\n if(CMAKE_VERSION VERSION_LESS 3.20)\n set(prefix_for_pc_file \"\\${pcfiledir}/..\")\n while(pc_datarootdir)\n get_filename_component(pc_datarootdir \"${pc_datarootdir}\" DIRECTORY)\n string(APPEND prefix_for_pc_file \"/..\")\n endwhile()\n else()\n cmake_path(RELATIVE_PATH CMAKE_INSTALL_PREFIX BASE_DIRECTORY CMAKE_INSTALL_DATAROOTDIR\n OUTPUT_VARIABLE prefix_for_pc_file)\n endif()\n endif()\n endif()\n join_paths(includedir_for_pc_file \"\\${prefix}\" \"${CMAKE_INSTALL_INCLUDEDIR}\")\n configure_file(\"${CMAKE_CURRENT_SOURCE_DIR}/tools/pybind11.pc.in\"\n \"${CMAKE_CURRENT_BINARY_DIR}/pybind11.pc\" @ONLY)\n install(FILES \"${CMAKE_CURRENT_BINARY_DIR}/pybind11.pc\"\n DESTINATION \"${CMAKE_INSTALL_DATAROOTDIR}/pkgconfig/\")\n\n # When building a wheel, include __init__.py's for modules\n # (see https://github.com/pybind/pybind11/pull/5552)\n if(DEFINED SKBUILD_PROJECT_NAME AND SKBUILD_PROJECT_NAME STREQUAL \"pybind11\")\n file(MAKE_DIRECTORY \"${CMAKE_CURRENT_BINARY_DIR}/empty\")\n file(TOUCH \"${CMAKE_CURRENT_BINARY_DIR}/empty/__init__.py\")\n install(FILES \"${CMAKE_CURRENT_BINARY_DIR}/empty/__init__.py\"\n DESTINATION \"${CMAKE_INSTALL_DATAROOTDIR}/\")\n install(FILES \"${CMAKE_CURRENT_BINARY_DIR}/empty/__init__.py\"\n DESTINATION \"${CMAKE_INSTALL_DATAROOTDIR}/pkgconfig/\")\n endif()\n\n # Uninstall target\n if(PYBIND11_MASTER_PROJECT)\n configure_file(\"${CMAKE_CURRENT_SOURCE_DIR}/tools/cmake_uninstall.cmake.in\"\n \"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake\" IMMEDIATE @ONLY)\n\n add_custom_target(uninstall COMMAND ${CMAKE_COMMAND} -P\n ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)\n endif()\nendif()\n\n# BUILD_TESTING takes priority, but only if this is the master project\nif(PYBIND11_MASTER_PROJECT AND DEFINED BUILD_TESTING)\n if(BUILD_TESTING)\n if(_pybind11_nopython)\n message(FATAL_ERROR \"Cannot activate tests in NOPYTHON mode\")\n else()\n add_subdirectory(tests)\n endif()\n endif()\nelse()\n if(PYBIND11_TEST)\n if(_pybind11_nopython)\n message(FATAL_ERROR \"Cannot activate tests in NOPYTHON mode\")\n else()\n add_subdirectory(tests)\n endif()\n endif()\nendif()\n\n# Better symmetry with find_package(pybind11 CONFIG) mode.\nif(NOT PYBIND11_MASTER_PROJECT)\n set(pybind11_FOUND\n TRUE\n CACHE INTERNAL \"True if pybind11 and all required components found on the system\")\nendif()\n" }, { "path": "CMakePresets.json", "content": "{\n \"version\": 6,\n \"configurePresets\": [\n {\n \"name\": \"default\",\n \"displayName\": \"Default\",\n \"binaryDir\": \"build\",\n \"generator\": \"Ninja\",\n \"errors\": {\n \"dev\": true,\n \"deprecated\": true\n },\n \"cacheVariables\": {\n \"CMAKE_BUILD_TYPE\": \"Debug\",\n \"CMAKE_EXPORT_COMPILE_COMMANDS\": true,\n \"DOWNLOAD_CATCH\": true,\n \"DOWNLOAD_EIGEN\": true,\n \"PYBIND11_FINDPYTHON\": \"NEW\",\n \"PYBIND11_WERROR\": true,\n \"CMAKE_COLOR_DIAGNOSTICS\": true\n }\n },\n {\n \"name\": \"venv\",\n \"displayName\": \"Venv\",\n \"inherits\": \"default\",\n \"cacheVariables\": {\n \"PYBIND11_CREATE_WITH_UV\": \"python3\",\n \"Python_ROOT_DIR\": \".venv\"\n }\n },\n {\n \"name\": \"tidy\",\n \"displayName\": \"Clang-tidy\",\n \"inherits\": \"default\",\n \"binaryDir\": \"build-tidy\",\n \"cacheVariables\": {\n \"CMAKE_CXX_CLANG_TIDY\": \"clang-tidy;--use-color;--warnings-as-errors=*\",\n \"CMAKE_CXX_STANDARD\": \"17\"\n }\n }\n ],\n \"buildPresets\": [\n {\n \"name\": \"default\",\n \"displayName\": \"Default Build\",\n \"configurePreset\": \"default\"\n },\n {\n \"name\": \"venv\",\n \"displayName\": \"Venv Build\",\n \"configurePreset\": \"venv\"\n },\n {\n \"name\": \"tidy\",\n \"displayName\": \"Clang-tidy Build\",\n \"configurePreset\": \"tidy\",\n \"nativeToolOptions\": [\"-k0\"]\n },\n {\n \"name\": \"tests\",\n \"displayName\": \"Tests (for workflow)\",\n \"configurePreset\": \"default\",\n \"targets\": [\"pytest\", \"cpptest\", \"test_cmake_build\", \"test_cross_module_rtti\"]\n },\n {\n \"name\": \"testsvenv\",\n \"displayName\": \"Tests Venv (for workflow)\",\n \"configurePreset\": \"venv\",\n \"targets\": [\"pytest\", \"cpptest\", \"test_cmake_build\", \"test_cross_module_rtti\"]\n }\n ],\n \"workflowPresets\": [\n {\n \"name\": \"default\",\n \"displayName\": \"Default Workflow\",\n \"steps\": [\n { \"type\": \"configure\", \"name\": \"default\" },\n { \"type\": \"build\", \"name\": \"default\" },\n { \"type\": \"build\", \"name\": \"tests\" }\n ]\n },\n {\n \"name\": \"venv\",\n \"displayName\": \"Default Workflow\",\n \"steps\": [\n { \"type\": \"configure\", \"name\": \"venv\" },\n { \"type\": \"build\", \"name\": \"venv\" },\n { \"type\": \"build\", \"name\": \"testsvenv\" }\n ]\n }\n ]\n}\n" }, { "path": "LICENSE", "content": "Copyright (c) 2016 Wenzel Jakob , All rights reserved.\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n\n1. Redistributions of source code must retain the above copyright notice, this\n list of conditions and the following disclaimer.\n\n2. Redistributions in binary form must reproduce the above copyright notice,\n this list of conditions and the following disclaimer in the documentation\n and/or other materials provided with the distribution.\n\n3. Neither the name of the copyright holder nor the names of its contributors\n may be used to endorse or promote products derived from this software\n without specific prior written permission.\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE\nDISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE\nFOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\nDAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR\nSERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER\nCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,\nOR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE\nOF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\n\nPlease also refer to the file .github/CONTRIBUTING.md, which clarifies licensing of\nexternal contributions to this project including patches, pull requests, etc.\n" }, { "path": "README.rst", "content": ".. figure:: https://github.com/pybind/pybind11/raw/master/docs/pybind11-logo.png\n :alt: pybind11 logo\n\n**pybind11 (v3) — Seamless interoperability between C++ and Python**\n\n|Latest Documentation Status| |Stable Documentation Status| |Gitter chat| |GitHub Discussions|\n\n|CI| |Build status| |SPEC 4 — Using and Creating Nightly Wheels|\n\n|Repology| |PyPI package| |Conda-forge| |Python Versions|\n\n`Setuptools example `_\n• `Scikit-build example `_\n• `CMake example `_\n\n.. start\n\n\n**pybind11** is a lightweight header-only library that exposes C++ types\nin Python and vice versa, mainly to create Python bindings of existing\nC++ code. Its goals and syntax are similar to the excellent\n`Boost.Python `_\nlibrary by David Abrahams: to minimize boilerplate code in traditional\nextension modules by inferring type information using compile-time\nintrospection.\n\nThe main issue with Boost.Python—and the reason for creating such a\nsimilar project—is Boost. Boost is an enormously large and complex suite\nof utility libraries that works with almost every C++ compiler in\nexistence. This compatibility has its cost: arcane template tricks and\nworkarounds are necessary to support the oldest and buggiest of compiler\nspecimens. Now that C++11-compatible compilers are widely available,\nthis heavy machinery has become an excessively large and unnecessary\ndependency.\n\nThink of this library as a tiny self-contained version of Boost.Python\nwith everything stripped away that isn't relevant for binding\ngeneration. Without comments, the core header files only require ~4K\nlines of code and depend on Python (CPython 3.8+, PyPy, or GraalPy) and the C++\nstandard library. This compact implementation was possible thanks to some C++11\nlanguage features (specifically: tuples, lambda functions and variadic\ntemplates). Since its creation, this library has grown beyond Boost.Python in\nmany ways, leading to dramatically simpler binding code in many common\nsituations.\n\nTutorial and reference documentation is provided at\n`pybind11.readthedocs.io `_.\nA PDF version of the manual is available\n`here `_.\nAnd the source code is always available at\n`github.com/pybind/pybind11 `_.\n\n\nCore features\n-------------\n\n\npybind11 can map the following core C++ features to Python:\n\n- Functions accepting and returning custom data structures per value,\n reference, or pointer\n- Instance methods and static methods\n- Overloaded functions\n- Instance attributes and static attributes\n- Arbitrary exception types\n- Enumerations\n- Callbacks\n- Iterators and ranges\n- Custom operators\n- Single and multiple inheritance\n- STL data structures\n- Smart pointers with reference counting like ``std::shared_ptr``\n- Internal references with correct reference counting\n- C++ classes with virtual (and pure virtual) methods can be extended\n in Python\n- Integrated NumPy support (NumPy 2 requires pybind11 2.12+)\n\nGoodies\n-------\n\nIn addition to the core functionality, pybind11 provides some extra\ngoodies:\n\n- CPython 3.8+, PyPy3 7.3.17+, and GraalPy 24.1+ are supported with an\n implementation-agnostic interface (see older versions for older CPython\n and PyPy versions).\n\n- It is possible to bind C++11 lambda functions with captured\n variables. The lambda capture data is stored inside the resulting\n Python function object.\n\n- pybind11 uses C++11 move constructors and move assignment operators\n whenever possible to efficiently transfer custom data types.\n\n- It's easy to expose the internal storage of custom data types through\n Pythons' buffer protocols. This is handy e.g. for fast conversion\n between C++ matrix classes like Eigen and NumPy without expensive\n copy operations.\n\n- pybind11 can automatically vectorize functions so that they are\n transparently applied to all entries of one or more NumPy array\n arguments.\n\n- Python's slice-based access and assignment operations can be\n supported with just a few lines of code.\n\n- Everything is contained in just a few header files; there is no need\n to link against any additional libraries.\n\n- Binaries are generally smaller by a factor of at least 2 compared to\n equivalent bindings generated by Boost.Python. A recent pybind11\n conversion of PyRosetta, an enormous Boost.Python binding project,\n `reported `_\n a binary size reduction of **5.4x** and compile time reduction by\n **5.8x**.\n\n- Function signatures are precomputed at compile time (using\n ``constexpr``), leading to smaller binaries.\n\n- With little extra effort, C++ types can be pickled and unpickled\n similar to regular Python objects.\n\nSupported platforms & compilers\n-------------------------------\n\npybind11 is exercised in continuous integration across a range of operating\nsystems, Python versions, C++ standards, and toolchains. For an up-to-date\nview of the combinations we currently test, please see the\n`pybind11 GitHub Actions `_\nlogs.\n\nThe test matrix naturally evolves over time as older platforms and compilers\nfall out of use and new ones are added by the community. Closely related\nversions of a tested compiler or platform will often work as well in practice,\nbut we cannot promise to validate every possible combination. If a\nconfiguration you rely on is missing from the matrix or regresses, issues and\npull requests to extend coverage are very welcome. At the same time, we need\nto balance the size of the test matrix with the available CI resources,\nsuch as GitHub's limits on concurrent jobs under the free tier.\n\nAbout\n-----\n\nThis project was created by `Wenzel\nJakob `_. Significant features and/or\nimprovements to the code were contributed by\nJonas Adler,\nLori A. Burns,\nSylvain Corlay,\nEric Cousineau,\nAaron Gokaslan,\nRalf Grosse-Kunstleve,\nTrent Houliston,\nAxel Huebl,\n@hulucc,\nYannick Jadoul,\nSergey Lyskov,\nJohan Mabille,\nTomasz Miąsko,\nDean Moldovan,\nBen Pritchard,\nJason Rhinelander,\nBoris Schäling,\nPim Schellart,\nHenry Schreiner,\nIvan Smirnov,\nDustin Spicuzza,\nBoris Staletic,\nEthan Steinberg,\nPatrick Stewart,\nIvor Wanders,\nand\nXiaofei Wang.\n\nWe thank Google for a generous financial contribution to the continuous\nintegration infrastructure used by this project.\n\n\nContributing\n~~~~~~~~~~~~\n\nSee the `contributing\nguide `_\nfor information on building and contributing to pybind11.\n\nLicense\n~~~~~~~\n\npybind11 is provided under a BSD-style license that can be found in the\n`LICENSE `_\nfile. By using, distributing, or contributing to this project, you agree\nto the terms and conditions of this license.\n\n.. |Latest Documentation Status| image:: https://readthedocs.org/projects/pybind11/badge?version=latest\n :target: http://pybind11.readthedocs.org/en/latest\n.. |Stable Documentation Status| image:: https://img.shields.io/badge/docs-stable-blue.svg\n :target: http://pybind11.readthedocs.org/en/stable\n.. |Gitter chat| image:: https://img.shields.io/gitter/room/gitterHQ/gitter.svg\n :target: https://gitter.im/pybind/Lobby\n.. |CI| image:: https://github.com/pybind/pybind11/workflows/CI/badge.svg\n :target: https://github.com/pybind/pybind11/actions\n.. |Build status| image:: https://ci.appveyor.com/api/projects/status/riaj54pn4h08xy40?svg=true\n :target: https://ci.appveyor.com/project/wjakob/pybind11\n.. |PyPI package| image:: https://img.shields.io/pypi/v/pybind11.svg\n :target: https://pypi.org/project/pybind11/\n.. |Conda-forge| image:: https://img.shields.io/conda/vn/conda-forge/pybind11.svg\n :target: https://github.com/conda-forge/pybind11-feedstock\n.. |Repology| image:: https://repology.org/badge/latest-versions/python:pybind11.svg\n :target: https://repology.org/project/python:pybind11/versions\n.. |Python Versions| image:: https://img.shields.io/pypi/pyversions/pybind11.svg\n :target: https://pypi.org/project/pybind11/\n.. |GitHub Discussions| image:: https://img.shields.io/static/v1?label=Discussions&message=Ask&color=blue&logo=github\n :target: https://github.com/pybind/pybind11/discussions\n.. |SPEC 4 — Using and Creating Nightly Wheels| image:: https://img.shields.io/badge/SPEC-4-green?labelColor=%23004811&color=%235CA038\n :target: https://scientific-python.org/specs/spec-0004/\n" }, { "path": "SECURITY.md", "content": "# Security Policy\n\n## Supported Versions\n\nSecurity updates are applied only to the latest release.\n\n## Reporting a Vulnerability\n\nIf you have discovered a security vulnerability in this project, please report it privately. **Do not disclose it as a public issue.** This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.\n\nPlease disclose it at [security advisory](https://github.com/pybind/pybind11/security/advisories/new).\n\nThis project is maintained by a team of volunteers on a reasonable-effort basis. As such, please give us at least 90 days to work on a fix before public exposure.\n" }, { "path": "docs/Doxyfile", "content": "PROJECT_NAME = pybind11\nINPUT = ../include/pybind11/\nRECURSIVE = YES\n\nGENERATE_HTML = NO\nGENERATE_LATEX = NO\nGENERATE_XML = YES\nXML_OUTPUT = .build/doxygenxml\nXML_PROGRAMLISTING = YES\n\nMACRO_EXPANSION = YES\nEXPAND_ONLY_PREDEF = YES\nEXPAND_AS_DEFINED = PYBIND11_RUNTIME_EXCEPTION\n\nALIASES = \"rst=\\verbatim embed:rst\"\nALIASES += \"endrst=\\endverbatim\"\n\nQUIET = YES\nWARNINGS = YES\nWARN_IF_UNDOCUMENTED = NO\nPREDEFINED = PYBIND11_NOINLINE\n" }, { "path": "docs/_static/css/custom.css", "content": ".highlight .go {\n color: #707070;\n}\n" }, { "path": "docs/advanced/cast/chrono.rst", "content": "Chrono\n======\n\nWhen including the additional header file :file:`pybind11/chrono.h` conversions\nfrom C++11 chrono datatypes to python datetime objects are automatically enabled.\nThis header also enables conversions of python floats (often from sources such\nas ``time.monotonic()``, ``time.perf_counter()`` and ``time.process_time()``)\ninto durations.\n\nAn overview of clocks in C++11\n------------------------------\n\nA point of confusion when using these conversions is the differences between\nclocks provided in C++11. There are three clock types defined by the C++11\nstandard and users can define their own if needed. Each of these clocks have\ndifferent properties and when converting to and from python will give different\nresults.\n\nThe first clock defined by the standard is ``std::chrono::system_clock``. This\nclock measures the current date and time. However, this clock changes with to\nupdates to the operating system time. For example, if your time is synchronised\nwith a time server this clock will change. This makes this clock a poor choice\nfor timing purposes but good for measuring the wall time.\n\nThe second clock defined in the standard is ``std::chrono::steady_clock``.\nThis clock ticks at a steady rate and is never adjusted. This makes it excellent\nfor timing purposes, however the value in this clock does not correspond to the\ncurrent date and time. Often this clock will be the amount of time your system\nhas been on, although it does not have to be. This clock will never be the same\nclock as the system clock as the system clock can change but steady clocks\ncannot.\n\nThe third clock defined in the standard is ``std::chrono::high_resolution_clock``.\nThis clock is the clock that has the highest resolution out of the clocks in the\nsystem. It is normally a typedef to either the system clock or the steady clock\nbut can be its own independent clock. This is important as when using these\nconversions as the types you get in python for this clock might be different\ndepending on the system.\nIf it is a typedef of the system clock, python will get datetime objects, but if\nit is a different clock they will be timedelta objects.\n\nProvided conversions\n--------------------\n\n.. rubric:: C++ to Python\n\n- ``std::chrono::system_clock::time_point`` → ``datetime.datetime``\n System clock times are converted to python datetime instances. They are\n in the local timezone, but do not have any timezone information attached\n to them (they are naive datetime objects).\n\n- ``std::chrono::duration`` → ``datetime.timedelta``\n Durations are converted to timedeltas, any precision in the duration\n greater than microseconds is lost by rounding towards zero.\n\n- ``std::chrono::[other_clocks]::time_point`` → ``datetime.timedelta``\n Any clock time that is not the system clock is converted to a time delta.\n This timedelta measures the time from the clocks epoch to now.\n\n.. rubric:: Python to C++\n\n- ``datetime.datetime`` or ``datetime.date`` or ``datetime.time`` → ``std::chrono::system_clock::time_point``\n Date/time objects are converted into system clock timepoints. Any\n timezone information is ignored and the type is treated as a naive\n object.\n\n- ``datetime.timedelta`` → ``std::chrono::duration``\n Time delta are converted into durations with microsecond precision.\n\n- ``datetime.timedelta`` → ``std::chrono::[other_clocks]::time_point``\n Time deltas that are converted into clock timepoints are treated as\n the amount of time from the start of the clocks epoch.\n\n- ``float`` → ``std::chrono::duration``\n Floats that are passed to C++ as durations be interpreted as a number of\n seconds. These will be converted to the duration using ``duration_cast``\n from the float.\n\n- ``float`` → ``std::chrono::[other_clocks]::time_point``\n Floats that are passed to C++ as time points will be interpreted as the\n number of seconds from the start of the clocks epoch.\n" }, { "path": "docs/advanced/cast/custom.rst", "content": ".. _custom_type_caster:\n\nCustom type casters\n===================\n\nSome applications may prefer custom type casters that convert between existing\nPython types and C++ types, similar to the ``list`` ↔ ``std::vector``\nand ``dict`` ↔ ``std::map`` conversions which are built into pybind11.\nImplementing custom type casters is fairly advanced usage.\nWhile it is recommended to use the pybind11 API as much as possible, more complex examples may\nrequire familiarity with the intricacies of the Python C API.\nYou can refer to the `Python/C API Reference Manual `_\nfor more information.\n\nThe following snippets demonstrate how this works for a very simple ``Point2D`` type.\nWe want this type to be convertible to C++ from Python types implementing the\n``Sequence`` protocol and having two elements of type ``float``.\nWhen returned from C++ to Python, it should be converted to a Python ``tuple[float, float]``.\nFor this type we could provide Python bindings for different arithmetic functions implemented\nin C++ (here demonstrated by a simple ``negate`` function).\n\n..\n PLEASE KEEP THE CODE BLOCKS IN SYNC WITH\n tests/test_docs_advanced_cast_custom.cpp\n tests/test_docs_advanced_cast_custom.py\n Ideally, change the test, run pre-commit (incl. clang-format),\n then copy the changed code back here.\n Also use TEST_SUBMODULE in tests, but PYBIND11_MODULE in docs.\n\n.. code-block:: cpp\n\n namespace user_space {\n\n struct Point2D {\n double x;\n double y;\n };\n\n Point2D negate(const Point2D &point) { return Point2D{-point.x, -point.y}; }\n\n } // namespace user_space\n\n\nThe following Python snippet demonstrates the intended usage of ``negate`` from the Python side:\n\n.. code-block:: python\n\n from my_math_module import docs_advanced_cast_custom as m\n\n point1 = [1.0, -1.0]\n point2 = m.negate(point1)\n assert point2 == (-1.0, 1.0)\n\nTo register the necessary conversion routines, it is necessary to add an\ninstantiation of the ``pybind11::detail::type_caster`` template.\nAlthough this is an implementation detail, adding an instantiation of this\ntype is explicitly allowed.\n\n.. code-block:: cpp\n\n namespace pybind11 {\n namespace detail {\n\n template <>\n struct type_caster {\n // This macro inserts a lot of boilerplate code and sets the type hint.\n // `io_name` is used to specify different type hints for arguments and return values.\n // The signature of our negate function would then look like:\n // `negate(Sequence[float]) -> tuple[float, float]`\n PYBIND11_TYPE_CASTER(user_space::Point2D, io_name(\"Sequence[float]\", \"tuple[float, float]\"));\n\n // C++ -> Python: convert `Point2D` to `tuple[float, float]`. The second and third arguments\n // are used to indicate the return value policy and parent object (for\n // return_value_policy::reference_internal) and are often ignored by custom casters.\n // The return value should reflect the type hint specified by the second argument of `io_name`.\n static handle\n cast(const user_space::Point2D &number, return_value_policy /*policy*/, handle /*parent*/) {\n return py::make_tuple(number.x, number.y).release();\n }\n\n // Python -> C++: convert a `PyObject` into a `Point2D` and return false upon failure. The\n // second argument indicates whether implicit conversions should be allowed.\n // The accepted types should reflect the type hint specified by the first argument of\n // `io_name`.\n bool load(handle src, bool /*convert*/) {\n // Check if handle is a Sequence\n if (!py::isinstance(src)) {\n return false;\n }\n auto seq = py::reinterpret_borrow(src);\n // Check if exactly two values are in the Sequence\n if (seq.size() != 2) {\n return false;\n }\n // Check if each element is either a float or an int\n for (auto item : seq) {\n if (!py::isinstance(item) && !py::isinstance(item)) {\n return false;\n }\n }\n value.x = seq[0].cast();\n value.y = seq[1].cast();\n return true;\n }\n };\n\n } // namespace detail\n } // namespace pybind11\n\n // Bind the negate function\n PYBIND11_MODULE(docs_advanced_cast_custom, m, py::mod_gil_not_used()) { m.def(\"negate\", user_space::negate); }\n\n.. note::\n\n A ``type_caster`` defined with ``PYBIND11_TYPE_CASTER(T, ...)`` requires\n that ``T`` is default-constructible (``value`` is first default constructed\n and then ``load()`` assigns to it).\n\n.. note::\n For further information on the ``return_value_policy`` argument of ``cast`` refer to :ref:`return_value_policies`.\n To learn about the ``convert`` argument of ``load`` see :ref:`nonconverting_arguments`.\n\n.. warning::\n\n When using custom type casters, it's important to declare them consistently\n in every compilation unit of the Python extension module to satisfy the C++ One Definition Rule\n (`ODR `_). Otherwise,\n undefined behavior can ensue.\n\n.. note::\n\n Using the type hint ``Sequence[float]`` signals to static type checkers, that not only tuples may be\n passed, but any type implementing the Sequence protocol, e.g., ``list[float]``.\n Unfortunately, that loses the length information ``tuple[float, float]`` provides.\n One way of still providing some length information in type hints is using ``typing.Annotated``, e.g.,\n ``Annotated[Sequence[float], 2]``, or further add libraries like\n `annotated-types `_.\n" }, { "path": "docs/advanced/cast/eigen.rst", "content": "Eigen\n#####\n\n`Eigen `_ is C++ header-based library for dense and\nsparse linear algebra. Due to its popularity and widespread adoption, pybind11\nprovides transparent conversion and limited mapping support between Eigen and\nScientific Python linear algebra data types.\n\nTo enable the built-in Eigen support you must include the optional header file\n:file:`pybind11/eigen.h`.\n\nPass-by-value\n=============\n\nWhen binding a function with ordinary Eigen dense object arguments (for\nexample, ``Eigen::MatrixXd``), pybind11 will accept any input value that is\nalready (or convertible to) a ``numpy.ndarray`` with dimensions compatible with\nthe Eigen type, copy its values into a temporary Eigen variable of the\nappropriate type, then call the function with this temporary variable.\n\nSparse matrices are similarly copied to or from\n``scipy.sparse.csr_matrix``/``scipy.sparse.csc_matrix`` objects.\n\nPass-by-reference\n=================\n\nOne major limitation of the above is that every data conversion implicitly\ninvolves a copy, which can be both expensive (for large matrices) and disallows\nbinding functions that change their (Matrix) arguments. Pybind11 allows you to\nwork around this by using Eigen's ``Eigen::Ref`` class much as you\nwould when writing a function taking a generic type in Eigen itself (subject to\nsome limitations discussed below).\n\nWhen calling a bound function accepting a ``Eigen::Ref``\ntype, pybind11 will attempt to avoid copying by using an ``Eigen::Map`` object\nthat maps into the source ``numpy.ndarray`` data: this requires both that the\ndata types are the same (e.g. ``dtype='float64'`` and ``MatrixType::Scalar`` is\n``double``); and that the storage is layout compatible. The latter limitation\nis discussed in detail in the section below, and requires careful\nconsideration: by default, numpy matrices and Eigen matrices are *not* storage\ncompatible.\n\nIf the numpy matrix cannot be used as is (either because its types differ, e.g.\npassing an array of integers to an Eigen parameter requiring doubles, or\nbecause the storage is incompatible), pybind11 makes a temporary copy and\npasses the copy instead.\n\nWhen a bound function parameter is instead ``Eigen::Ref`` (note the\nlack of ``const``), pybind11 will only allow the function to be called if it\ncan be mapped *and* if the numpy array is writeable (that is\n``a.flags.writeable`` is true). Any access (including modification) made to\nthe passed variable will be transparently carried out directly on the\n``numpy.ndarray``.\n\nThis means you can write code such as the following and have it work as\nexpected:\n\n.. code-block:: cpp\n\n void scale_by_2(Eigen::Ref v) {\n v *= 2;\n }\n\nNote, however, that you will likely run into limitations due to numpy and\nEigen's difference default storage order for data; see the below section on\n:ref:`storage_orders` for details on how to bind code that won't run into such\nlimitations.\n\n.. note::\n\n Passing by reference is not supported for sparse types.\n\nReturning values to Python\n==========================\n\nWhen returning an ordinary dense Eigen matrix type to numpy (e.g.\n``Eigen::MatrixXd`` or ``Eigen::RowVectorXf``) pybind11 keeps the matrix and\nreturns a numpy array that directly references the Eigen matrix: no copy of the\ndata is performed. The numpy array will have ``array.flags.owndata`` set to\n``False`` to indicate that it does not own the data, and the lifetime of the\nstored Eigen matrix will be tied to the returned ``array``.\n\nIf you bind a function with a non-reference, ``const`` return type (e.g.\n``const Eigen::MatrixXd``), the same thing happens except that pybind11 also\nsets the numpy array's ``writeable`` flag to false.\n\nIf you return an lvalue reference or pointer, the usual pybind11 rules apply,\nas dictated by the binding function's return value policy (see the\ndocumentation on :ref:`return_value_policies` for full details). That means,\nwithout an explicit return value policy, lvalue references will be copied and\npointers will be managed by pybind11. In order to avoid copying, you should\nexplicitly specify an appropriate return value policy, as in the following\nexample:\n\n.. code-block:: cpp\n\n class MyClass {\n Eigen::MatrixXd big_mat = Eigen::MatrixXd::Zero(10000, 10000);\n public:\n Eigen::MatrixXd &getMatrix() { return big_mat; }\n const Eigen::MatrixXd &viewMatrix() { return big_mat; }\n };\n\n // Later, in binding code:\n py::class_(m, \"MyClass\")\n .def(py::init<>())\n .def(\"copy_matrix\", &MyClass::getMatrix) // Makes a copy!\n .def(\"get_matrix\", &MyClass::getMatrix, py::return_value_policy::reference_internal)\n .def(\"view_matrix\", &MyClass::viewMatrix, py::return_value_policy::reference_internal)\n ;\n\n.. code-block:: python\n\n a = MyClass()\n m = a.get_matrix() # flags.writeable = True, flags.owndata = False\n v = a.view_matrix() # flags.writeable = False, flags.owndata = False\n c = a.copy_matrix() # flags.writeable = True, flags.owndata = True\n # m[5,6] and v[5,6] refer to the same element, c[5,6] does not.\n\nNote in this example that ``py::return_value_policy::reference_internal`` is\nused to tie the life of the MyClass object to the life of the returned arrays.\n\nYou may also return an ``Eigen::Ref``, ``Eigen::Map`` or other map-like Eigen\nobject (for example, the return value of ``matrix.block()`` and related\nmethods) that map into a dense Eigen type. When doing so, the default\nbehaviour of pybind11 is to simply reference the returned data: you must take\ncare to ensure that this data remains valid! You may ask pybind11 to\nexplicitly *copy* such a return value by using the\n``py::return_value_policy::copy`` policy when binding the function. You may\nalso use ``py::return_value_policy::reference_internal`` or a\n``py::keep_alive`` to ensure the data stays valid as long as the returned numpy\narray does.\n\nWhen returning such a reference of map, pybind11 additionally respects the\nreadonly-status of the returned value, marking the numpy array as non-writeable\nif the reference or map was itself read-only.\n\n.. note::\n\n Sparse types are always copied when returned.\n\n.. _storage_orders:\n\nStorage orders\n==============\n\nPassing arguments via ``Eigen::Ref`` has some limitations that you must be\naware of in order to effectively pass matrices by reference. First and\nforemost is that the default ``Eigen::Ref`` class requires\ncontiguous storage along columns (for column-major types, the default in Eigen)\nor rows if ``MatrixType`` is specifically an ``Eigen::RowMajor`` storage type.\nThe former, Eigen's default, is incompatible with ``numpy``'s default row-major\nstorage, and so you will not be able to pass numpy arrays to Eigen by reference\nwithout making one of two changes.\n\n(Note that this does not apply to vectors (or column or row matrices): for such\ntypes the \"row-major\" and \"column-major\" distinction is meaningless).\n\nThe first approach is to change the use of ``Eigen::Ref`` to the\nmore general ``Eigen::Ref>`` (or similar type with a fully dynamic stride type in the\nthird template argument). Since this is a rather cumbersome type, pybind11\nprovides a ``py::EigenDRef`` type alias for your convenience (along\nwith EigenDMap for the equivalent Map, and EigenDStride for just the stride\ntype).\n\nThis type allows Eigen to map into any arbitrary storage order. This is not\nthe default in Eigen for performance reasons: contiguous storage allows\nvectorization that cannot be done when storage is not known to be contiguous at\ncompile time. The default ``Eigen::Ref`` stride type allows non-contiguous\nstorage along the outer dimension (that is, the rows of a column-major matrix\nor columns of a row-major matrix), but not along the inner dimension.\n\nThis type, however, has the added benefit of also being able to map numpy array\nslices. For example, the following (contrived) example uses Eigen with a numpy\nslice to multiply by 2 all coefficients that are both on even rows (0, 2, 4,\n...) and in columns 2, 5, or 8:\n\n.. code-block:: cpp\n\n m.def(\"scale\", [](py::EigenDRef m, double c) { m *= c; });\n\n.. code-block:: python\n\n # a = np.array(...)\n scale_by_2(myarray[0::2, 2:9:3])\n\nThe second approach to avoid copying is more intrusive: rearranging the\nunderlying data types to not run into the non-contiguous storage problem in the\nfirst place. In particular, that means using matrices with ``Eigen::RowMajor``\nstorage, where appropriate, such as:\n\n.. code-block:: cpp\n\n using RowMatrixXd = Eigen::Matrix;\n // Use RowMatrixXd instead of MatrixXd\n\nNow bound functions accepting ``Eigen::Ref`` arguments will be\ncallable with numpy's (default) arrays without involving a copying.\n\nYou can, alternatively, change the storage order that numpy arrays use by\nadding the ``order='F'`` option when creating an array:\n\n.. code-block:: python\n\n myarray = np.array(source, order=\"F\")\n\nSuch an object will be passable to a bound function accepting an\n``Eigen::Ref`` (or similar column-major Eigen type).\n\nOne major caveat with this approach, however, is that it is not entirely as\neasy as simply flipping all Eigen or numpy usage from one to the other: some\noperations may alter the storage order of a numpy array. For example, ``a2 =\narray.transpose()`` results in ``a2`` being a view of ``array`` that references\nthe same data, but in the opposite storage order!\n\nWhile this approach allows fully optimized vectorized calculations in Eigen, it\ncannot be used with array slices, unlike the first approach.\n\nWhen *returning* a matrix to Python (either a regular matrix, a reference via\n``Eigen::Ref<>``, or a map/block into a matrix), no special storage\nconsideration is required: the created numpy array will have the required\nstride that allows numpy to properly interpret the array, whatever its storage\norder.\n\nFailing rather than copying\n===========================\n\nThe default behaviour when binding ``Eigen::Ref`` Eigen\nreferences is to copy matrix values when passed a numpy array that does not\nconform to the element type of ``MatrixType`` or does not have a compatible\nstride layout. If you want to explicitly avoid copying in such a case, you\nshould bind arguments using the ``py::arg().noconvert()`` annotation (as\ndescribed in the :ref:`nonconverting_arguments` documentation).\n\nThe following example shows an example of arguments that don't allow data\ncopying to take place:\n\n.. code-block:: cpp\n\n // The method and function to be bound:\n class MyClass {\n // ...\n double some_method(const Eigen::Ref &matrix) { /* ... */ }\n };\n float some_function(const Eigen::Ref &big,\n const Eigen::Ref &small) {\n // ...\n }\n\n // The associated binding code:\n using namespace pybind11::literals; // for \"arg\"_a\n py::class_(m, \"MyClass\")\n // ... other class definitions\n .def(\"some_method\", &MyClass::some_method, py::arg().noconvert());\n\n m.def(\"some_function\", &some_function,\n \"big\"_a.noconvert(), // <- Don't allow copying for this arg\n \"small\"_a // <- This one can be copied if needed\n );\n\nWith the above binding code, attempting to call the ``some_method(m)``\nmethod on a ``MyClass`` object, or attempting to call ``some_function(m, m2)``\nwill raise a ``RuntimeError`` rather than making a temporary copy of the array.\nIt will, however, allow the ``m2`` argument to be copied into a temporary if\nnecessary.\n\nNote that explicitly specifying ``.noconvert()`` is not required for *mutable*\nEigen references (e.g. ``Eigen::Ref`` without ``const`` on the\n``MatrixXd``): mutable references will never be called with a temporary copy.\n\nVectors versus column/row matrices\n==================================\n\nEigen and numpy have fundamentally different notions of a vector. In Eigen, a\nvector is simply a matrix with the number of columns or rows set to 1 at\ncompile time (for a column vector or row vector, respectively). NumPy, in\ncontrast, has comparable 2-dimensional 1xN and Nx1 arrays, but *also* has\n1-dimensional arrays of size N.\n\nWhen passing a 2-dimensional 1xN or Nx1 array to Eigen, the Eigen type must\nhave matching dimensions: That is, you cannot pass a 2-dimensional Nx1 numpy\narray to an Eigen value expecting a row vector, or a 1xN numpy array as a\ncolumn vector argument.\n\nOn the other hand, pybind11 allows you to pass 1-dimensional arrays of length N\nas Eigen parameters. If the Eigen type can hold a column vector of length N it\nwill be passed as such a column vector. If not, but the Eigen type constraints\nwill accept a row vector, it will be passed as a row vector. (The column\nvector takes precedence when both are supported, for example, when passing a\n1D numpy array to a MatrixXd argument). Note that the type need not be\nexplicitly a vector: it is permitted to pass a 1D numpy array of size 5 to an\nEigen ``Matrix``: you would end up with a 1x5 Eigen matrix.\nPassing the same to an ``Eigen::MatrixXd`` would result in a 5x1 Eigen matrix.\n\nWhen returning an Eigen vector to numpy, the conversion is ambiguous: a row\nvector of length 4 could be returned as either a 1D array of length 4, or as a\n2D array of size 1x4. When encountering such a situation, pybind11 compromises\nby considering the returned Eigen type: if it is a compile-time vector--that\nis, the type has either the number of rows or columns set to 1 at compile\ntime--pybind11 converts to a 1D numpy array when returning the value. For\ninstances that are a vector only at run-time (e.g. ``MatrixXd``,\n``Matrix``), pybind11 returns the vector as a 2D array to\nnumpy. If this isn't want you want, you can use ``array.reshape(...)`` to get\na view of the same data in the desired dimensions.\n\n.. seealso::\n\n The file :file:`tests/test_eigen.cpp` contains a complete example that\n shows how to pass Eigen sparse and dense data types in more detail.\n" }, { "path": "docs/advanced/cast/functional.rst", "content": "Functional\n##########\n\nThe following features must be enabled by including :file:`pybind11/functional.h`.\n\n\nCallbacks and passing anonymous functions\n=========================================\n\nThe C++11 standard brought lambda functions and the generic polymorphic\nfunction wrapper ``std::function<>`` to the C++ programming language, which\nenable powerful new ways of working with functions. Lambda functions come in\ntwo flavors: stateless lambda function resemble classic function pointers that\nlink to an anonymous piece of code, while stateful lambda functions\nadditionally depend on captured variables that are stored in an anonymous\n*lambda closure object*.\n\nHere is a simple example of a C++ function that takes an arbitrary function\n(stateful or stateless) with signature ``int -> int`` as an argument and runs\nit with the value 10.\n\n.. code-block:: cpp\n\n int func_arg(const std::function &f) {\n return f(10);\n }\n\nThe example below is more involved: it takes a function of signature ``int -> int``\nand returns another function of the same kind. The return value is a stateful\nlambda function, which stores the value ``f`` in the capture object and adds 1 to\nits return value upon execution.\n\n.. code-block:: cpp\n\n std::function func_ret(const std::function &f) {\n return [f](int i) {\n return f(i) + 1;\n };\n }\n\nThis example demonstrates using python named parameters in C++ callbacks which\nrequires using ``py::cpp_function`` as a wrapper. Usage is similar to defining\nmethods of classes:\n\n.. code-block:: cpp\n\n py::cpp_function func_cpp() {\n return py::cpp_function([](int i) { return i+1; },\n py::arg(\"number\"));\n }\n\nAfter including the extra header file :file:`pybind11/functional.h`, it is almost\ntrivial to generate binding code for all of these functions.\n\n.. code-block:: cpp\n\n #include \n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n m.def(\"func_arg\", &func_arg);\n m.def(\"func_ret\", &func_ret);\n m.def(\"func_cpp\", &func_cpp);\n }\n\nThe following interactive session shows how to call them from Python.\n\n.. code-block:: pycon\n\n $ python\n >>> import example\n >>> def square(i):\n ... return i * i\n ...\n >>> example.func_arg(square)\n 100L\n >>> square_plus_1 = example.func_ret(square)\n >>> square_plus_1(4)\n 17L\n >>> plus_1 = func_cpp()\n >>> plus_1(number=43)\n 44L\n\n.. warning::\n\n Keep in mind that passing a function from C++ to Python (or vice versa)\n will instantiate a piece of wrapper code that translates function\n invocations between the two languages. Naturally, this translation\n increases the computational cost of each function call somewhat. A\n problematic situation can arise when a function is copied back and forth\n between Python and C++ many times in a row, in which case the underlying\n wrappers will accumulate correspondingly. The resulting long sequence of\n C++ -> Python -> C++ -> ... roundtrips can significantly decrease\n performance.\n\n There is one exception: pybind11 detects case where a stateless function\n (i.e. a function pointer or a lambda function without captured variables)\n is passed as an argument to another C++ function exposed in Python. In this\n case, there is no overhead. Pybind11 will extract the underlying C++\n function pointer from the wrapped function to sidestep a potential C++ ->\n Python -> C++ roundtrip. This is demonstrated in :file:`tests/test_callbacks.cpp`.\n\n.. note::\n\n This functionality is very useful when generating bindings for callbacks in\n C++ libraries (e.g. GUI libraries, asynchronous networking libraries, etc.).\n\n The file :file:`tests/test_callbacks.cpp` contains a complete example\n that demonstrates how to work with callbacks and anonymous functions in\n more detail.\n" }, { "path": "docs/advanced/cast/index.rst", "content": ".. _type-conversions:\n\nType conversions\n################\n\nApart from enabling cross-language function calls, a fundamental problem\nthat a binding tool like pybind11 must address is to provide access to\nnative Python types in C++ and vice versa. There are three fundamentally\ndifferent ways to do this—which approach is preferable for a particular type\ndepends on the situation at hand.\n\n1. Use a native C++ type everywhere. In this case, the type must be wrapped\n using pybind11-generated bindings so that Python can interact with it.\n\n2. Use a native Python type everywhere. It will need to be wrapped so that\n C++ functions can interact with it.\n\n3. Use a native C++ type on the C++ side and a native Python type on the\n Python side. pybind11 refers to this as a *type conversion*.\n\n Type conversions are the most \"natural\" option in the sense that native\n (non-wrapped) types are used everywhere. The main downside is that a copy\n of the data must be made on every Python ↔ C++ transition: this is\n needed since the C++ and Python versions of the same type generally won't\n have the same memory layout.\n\n pybind11 can perform many kinds of conversions automatically. An overview\n is provided in the table \":ref:`conversion_table`\".\n\nThe following subsections discuss the differences between these options in more\ndetail. The main focus in this section is on type conversions, which represent\nthe last case of the above list.\n\n.. toctree::\n :maxdepth: 1\n\n overview\n strings\n stl\n functional\n chrono\n eigen\n custom\n" }, { "path": "docs/advanced/cast/overview.rst", "content": "Overview\n########\n\n.. rubric:: 1. Native type in C++, wrapper in Python\n\nExposing a custom C++ type using :class:`py::class_` was covered in detail\nin the :doc:`/classes` section. There, the underlying data structure is\nalways the original C++ class while the :class:`py::class_` wrapper provides\na Python interface. Internally, when an object like this is sent from C++ to\nPython, pybind11 will just add the outer wrapper layer over the native C++\nobject. Getting it back from Python is just a matter of peeling off the\nwrapper.\n\n.. rubric:: 2. Wrapper in C++, native type in Python\n\nThis is the exact opposite situation. Now, we have a type which is native to\nPython, like a ``tuple`` or a ``list``. One way to get this data into C++ is\nwith the :class:`py::object` family of wrappers. These are explained in more\ndetail in the :doc:`/advanced/pycpp/object` section. We'll just give a quick\nexample here:\n\n.. code-block:: cpp\n\n void print_list(py::list my_list) {\n for (auto item : my_list)\n std::cout << item << \" \";\n }\n\n.. code-block:: pycon\n\n >>> print_list([1, 2, 3])\n 1 2 3\n\nThe Python ``list`` is not converted in any way -- it's just wrapped in a C++\n:class:`py::list` class. At its core it's still a Python object. Copying a\n:class:`py::list` will do the usual reference-counting like in Python.\nReturning the object to Python will just remove the thin wrapper.\n\n.. rubric:: 3. Converting between native C++ and Python types\n\nIn the previous two cases we had a native type in one language and a wrapper in\nthe other. Now, we have native types on both sides and we convert between them.\n\n.. code-block:: cpp\n\n void print_vector(const std::vector &v) {\n for (auto item : v)\n std::cout << item << \"\\n\";\n }\n\n.. code-block:: pycon\n\n >>> print_vector([1, 2, 3])\n 1 2 3\n\nIn this case, pybind11 will construct a new ``std::vector`` and copy each\nelement from the Python ``list``. The newly constructed object will be passed\nto ``print_vector``. The same thing happens in the other direction: a new\n``list`` is made to match the value returned from C++.\n\nLots of these conversions are supported out of the box, as shown in the table\nbelow. They are very convenient, but keep in mind that these conversions are\nfundamentally based on copying data. This is perfectly fine for small immutable\ntypes but it may become quite expensive for large data structures. This can be\navoided by overriding the automatic conversion with a custom wrapper (i.e. the\nabove-mentioned approach 1). This requires some manual effort and more details\nare available in the :ref:`opaque` section.\n\n.. _conversion_table:\n\nList of all builtin conversions\n-------------------------------\n\nThe following basic data types are supported out of the box (some may require\nan additional extension header to be included). To pass other data structures\nas arguments and return values, refer to the section on binding :ref:`classes`.\n\n+------------------------------------+---------------------------+-----------------------------------+\n| Data type | Description | Header file |\n+====================================+===========================+===================================+\n| ``int8_t``, ``uint8_t`` | 8-bit integers | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``int16_t``, ``uint16_t`` | 16-bit integers | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``int32_t``, ``uint32_t`` | 32-bit integers | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``int64_t``, ``uint64_t`` | 64-bit integers | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``ssize_t``, ``size_t`` | Platform-dependent size | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``float``, ``double`` | Floating point types | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``bool`` | Two-state Boolean type | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``char`` | Character literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``char16_t`` | UTF-16 character literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``char32_t`` | UTF-32 character literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``wchar_t`` | Wide character literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``const char *`` | UTF-8 string literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``const char16_t *`` | UTF-16 string literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``const char32_t *`` | UTF-32 string literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``const wchar_t *`` | Wide string literal | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::string`` | STL dynamic UTF-8 string | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::u16string`` | STL dynamic UTF-16 string | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::u32string`` | STL dynamic UTF-32 string | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::wstring`` | STL dynamic wide string | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::string_view``, | STL C++17 string views | :file:`pybind11/pybind11.h` |\n| ``std::u16string_view``, etc. | | |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::pair`` | Pair of two custom types | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::tuple<...>`` | Arbitrary tuple of types | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::reference_wrapper<...>`` | Reference type wrapper | :file:`pybind11/pybind11.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::complex`` | Complex numbers | :file:`pybind11/complex.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::array`` | STL static array | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::vector`` | STL dynamic array | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::deque`` | STL double-ended queue | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::valarray`` | STL value array | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::list`` | STL linked list | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::map`` | STL ordered map | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::unordered_map`` | STL unordered map | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::set`` | STL ordered set | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::unordered_set`` | STL unordered set | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::optional`` | STL optional type (C++17) | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::experimental::optional`` | STL optional type (exp.) | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::variant<...>`` | Type-safe union (C++17) | :file:`pybind11/stl.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::filesystem::path`` | STL path (C++17) [#]_ | :file:`pybind11/stl/filesystem.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::function<...>`` | STL polymorphic function | :file:`pybind11/functional.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::chrono::duration<...>`` | STL time duration | :file:`pybind11/chrono.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``std::chrono::time_point<...>`` | STL date/time | :file:`pybind11/chrono.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``Eigen::Matrix<...>`` | Eigen: dense matrix | :file:`pybind11/eigen.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``Eigen::Map<...>`` | Eigen: mapped memory | :file:`pybind11/eigen.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n| ``Eigen::SparseMatrix<...>`` | Eigen: sparse matrix | :file:`pybind11/eigen.h` |\n+------------------------------------+---------------------------+-----------------------------------+\n\n.. [#] ``std::filesystem::path`` is converted to ``pathlib.Path`` and\n can be loaded from ``os.PathLike``, ``str``, and ``bytes``.\n" }, { "path": "docs/advanced/cast/stl.rst", "content": "STL containers\n##############\n\nAutomatic conversion\n====================\n\nWhen including the additional header file :file:`pybind11/stl.h`, conversions\nbetween ``std::vector<>``/``std::deque<>``/``std::list<>``/``std::array<>``/``std::valarray<>``,\n``std::set<>``/``std::unordered_set<>``, and\n``std::map<>``/``std::unordered_map<>`` and the Python ``list``, ``set`` and\n``dict`` data structures are automatically enabled. The types ``std::pair<>``\nand ``std::tuple<>`` are already supported out of the box with just the core\n:file:`pybind11/pybind11.h` header.\n\nThe major downside of these implicit conversions is that containers must be\nconverted (i.e. copied) on every Python->C++ and C++->Python transition, which\ncan have implications on the program semantics and performance. Please read the\nnext sections for more details and alternative approaches that avoid this.\n\n.. note::\n\n Arbitrary nesting of any of these types is possible.\n\n.. seealso::\n\n The file :file:`tests/test_stl.cpp` contains a complete\n example that demonstrates how to pass STL data types in more detail.\n\n.. _cpp17_container_casters:\n\nC++17 library containers\n========================\n\nThe :file:`pybind11/stl.h` header also includes support for ``std::optional<>``\nand ``std::variant<>``. These require a C++17 compiler and standard library.\nIn C++14 mode, ``std::experimental::optional<>`` is supported if available.\n\nVarious versions of these containers also exist for C++11 (e.g. in Boost).\npybind11 provides an easy way to specialize the ``type_caster`` for such\ntypes:\n\n.. code-block:: cpp\n\n // `boost::optional` as an example -- can be any `std::optional`-like container\n namespace PYBIND11_NAMESPACE { namespace detail {\n template \n struct type_caster> : optional_caster> {};\n }}\n\nThe above should be placed in a header file and included in all translation units\nwhere automatic conversion is needed. Similarly, a specialization can be provided\nfor custom variant types:\n\n.. code-block:: cpp\n\n // `boost::variant` as an example -- can be any `std::variant`-like container\n namespace PYBIND11_NAMESPACE { namespace detail {\n template \n struct type_caster> : variant_caster> {};\n\n // Specifies the function used to visit the variant -- `apply_visitor` instead of `visit`\n template <>\n struct visit_helper {\n template \n static auto call(Args &&...args) -> decltype(boost::apply_visitor(args...)) {\n return boost::apply_visitor(args...);\n }\n };\n }} // namespace PYBIND11_NAMESPACE::detail\n\nThe ``visit_helper`` specialization is not required if your ``name::variant`` provides\na ``name::visit()`` function. For any other function name, the specialization must be\nincluded to tell pybind11 how to visit the variant.\n\n.. warning::\n\n When converting a ``variant`` type, pybind11 follows the same rules as when\n determining which function overload to call (:ref:`overload_resolution`), and\n so the same caveats hold. In particular, the order in which the ``variant``'s\n alternatives are listed is important, since pybind11 will try conversions in\n this order. This means that, for example, when converting ``variant``,\n the ``bool`` variant will never be selected, as any Python ``bool`` is already\n an ``int`` and is convertible to a C++ ``int``. Changing the order of alternatives\n (and using ``variant``, in this example) provides a solution.\n\n.. note::\n\n pybind11 only supports the modern implementation of ``boost::variant``\n which makes use of variadic templates. This requires Boost 1.56 or newer.\n\n.. _opaque:\n\nMaking opaque types\n===================\n\npybind11 heavily relies on a template matching mechanism to convert parameters\nand return values that are constructed from STL data types such as vectors,\nlinked lists, hash tables, etc. This even works in a recursive manner, for\ninstance to deal with lists of hash maps of pairs of elementary and custom\ntypes, etc.\n\nHowever, a fundamental limitation of this approach is that internal conversions\nbetween Python and C++ types involve a copy operation that prevents\npass-by-reference semantics. What does this mean?\n\nSuppose we bind the following function\n\n.. code-block:: cpp\n\n void append_1(std::vector &v) {\n v.push_back(1);\n }\n\nand call it from Python, the following happens:\n\n.. code-block:: pycon\n\n >>> v = [5, 6]\n >>> append_1(v)\n >>> print(v)\n [5, 6]\n\nAs you can see, when passing STL data structures by reference, modifications\nare not propagated back the Python side. A similar situation arises when\nexposing STL data structures using the ``def_readwrite`` or ``def_readonly``\nfunctions:\n\n.. code-block:: cpp\n\n /* ... definition ... */\n\n class MyClass {\n std::vector contents;\n };\n\n /* ... binding code ... */\n\n py::class_(m, \"MyClass\")\n .def(py::init<>())\n .def_readwrite(\"contents\", &MyClass::contents);\n\nIn this case, properties can be read and written in their entirety. However, an\n``append`` operation involving such a list type has no effect:\n\n.. code-block:: pycon\n\n >>> m = MyClass()\n >>> m.contents = [5, 6]\n >>> print(m.contents)\n [5, 6]\n >>> m.contents.append(7)\n >>> print(m.contents)\n [5, 6]\n\nFinally, the involved copy operations can be costly when dealing with very\nlarge lists. To deal with all of the above situations, pybind11 provides a\nmacro named ``PYBIND11_MAKE_OPAQUE(T)`` that disables the template-based\nconversion machinery of types, thus rendering them *opaque*. The contents of\nopaque objects are never inspected or extracted, hence they *can* be passed by\nreference. For instance, to turn ``std::vector`` into an opaque type, add\nthe declaration\n\n.. code-block:: cpp\n\n PYBIND11_MAKE_OPAQUE(std::vector)\n\nbefore any binding code (e.g. invocations to ``class_::def()``, etc.). This\nmacro must be specified at the top level (and outside of any namespaces), since\nit adds a template instantiation of ``type_caster``. If your binding code consists of\nmultiple compilation units, it must be present in every file (typically via a\ncommon header) preceding any usage of ``std::vector``. Opaque types must\nalso have a corresponding ``py::class_`` declaration to associate them with a\nname in Python, and to define a set of available operations, e.g.:\n\n.. code-block:: cpp\n\n py::class_>(m, \"IntVector\")\n .def(py::init<>())\n .def(\"clear\", &std::vector::clear)\n .def(\"pop_back\", &std::vector::pop_back)\n .def(\"__len__\", [](const std::vector &v) { return v.size(); })\n .def(\"__iter__\", [](std::vector &v) {\n return py::make_iterator(v.begin(), v.end());\n }, py::keep_alive<0, 1>()) /* Keep vector alive while iterator is used */\n // ....\n\n.. seealso::\n\n The file :file:`tests/test_opaque_types.cpp` contains a complete\n example that demonstrates how to create and expose opaque types using\n pybind11 in more detail.\n\n.. _stl_bind:\n\nBinding STL containers\n======================\n\nThe ability to expose STL containers as native Python objects is a fairly\ncommon request, hence pybind11 also provides an optional header file named\n:file:`pybind11/stl_bind.h` that does exactly this. The mapped containers try\nto match the behavior of their native Python counterparts as much as possible.\n\nThe following example showcases usage of :file:`pybind11/stl_bind.h`:\n\n.. code-block:: cpp\n\n // Don't forget this\n #include \n\n PYBIND11_MAKE_OPAQUE(std::vector)\n PYBIND11_MAKE_OPAQUE(std::map)\n\n // ...\n\n // later in binding code:\n py::bind_vector>(m, \"VectorInt\");\n py::bind_map>(m, \"MapStringDouble\");\n\nWhen binding STL containers pybind11 considers the types of the container's\nelements to decide whether the container should be confined to the local module\n(via the :ref:`module_local` feature). If the container element types are\nanything other than already-bound custom types bound without\n``py::module_local()`` the container binding will have ``py::module_local()``\napplied. This includes converting types such as numeric types, strings, Eigen\ntypes; and types that have not yet been bound at the time of the stl container\nbinding. This module-local binding is designed to avoid potential conflicts\nbetween module bindings (for example, from two separate modules each attempting\nto bind ``std::vector`` as a python type).\n\nIt is possible to override this behavior to force a definition to be either\nmodule-local or global. To do so, you can pass the attributes\n``py::module_local()`` (to make the binding module-local) or\n``py::module_local(false)`` (to make the binding global) into the\n``py::bind_vector`` or ``py::bind_map`` arguments:\n\n.. code-block:: cpp\n\n py::bind_vector>(m, \"VectorInt\", py::module_local(false));\n\nNote, however, that such a global binding would make it impossible to load this\nmodule at the same time as any other pybind module that also attempts to bind\nthe same container type (``std::vector`` in the above example).\n\nSee :ref:`module_local` for more details on module-local bindings.\n\n.. seealso::\n\n The file :file:`tests/test_stl_binders.cpp` shows how to use the\n convenience STL container wrappers.\n" }, { "path": "docs/advanced/cast/strings.rst", "content": "Strings, bytes and Unicode conversions\n######################################\n\nPassing Python strings to C++\n=============================\n\nWhen a Python ``str`` is passed from Python to a C++ function that accepts\n``std::string`` or ``char *`` as arguments, pybind11 will encode the Python\nstring to UTF-8. All Python ``str`` can be encoded in UTF-8, so this operation\ndoes not fail.\n\nThe C++ language is encoding agnostic. It is the responsibility of the\nprogrammer to track encodings. It's often easiest to simply `use UTF-8\neverywhere `_.\n\n.. code-block:: c++\n\n m.def(\"utf8_test\",\n [](const std::string &s) {\n cout << \"utf-8 is icing on the cake.\\n\";\n cout << s;\n }\n );\n m.def(\"utf8_charptr\",\n [](const char *s) {\n cout << \"My favorite food is\\n\";\n cout << s;\n }\n );\n\n.. code-block:: pycon\n\n >>> utf8_test(\"🎂\")\n utf-8 is icing on the cake.\n 🎂\n\n >>> utf8_charptr(\"🍕\")\n My favorite food is\n 🍕\n\n.. note::\n\n Some terminal emulators do not support UTF-8 or emoji fonts and may not\n display the example above correctly.\n\nThe results are the same whether the C++ function accepts arguments by value or\nreference, and whether or not ``const`` is used.\n\nPassing bytes to C++\n--------------------\n\nA Python ``bytes`` object will be passed to C++ functions that accept\n``std::string`` or ``char*`` *without* conversion. In order to make a function\n*only* accept ``bytes`` (and not ``str``), declare it as taking a ``py::bytes``\nargument.\n\n\nReturning C++ strings to Python\n===============================\n\nWhen a C++ function returns a ``std::string`` or ``char*`` to a Python caller,\n**pybind11 will assume that the string is valid UTF-8** and will decode it to a\nnative Python ``str``, using the same API as Python uses to perform\n``bytes.decode('utf-8')``. If this implicit conversion fails, pybind11 will\nraise a ``UnicodeDecodeError``.\n\n.. code-block:: c++\n\n m.def(\"std_string_return\",\n []() {\n return std::string(\"This string needs to be UTF-8 encoded\");\n }\n );\n\n.. code-block:: pycon\n\n >>> isinstance(example.std_string_return(), str)\n True\n\n\nBecause UTF-8 is inclusive of pure ASCII, there is never any issue with\nreturning a pure ASCII string to Python. If there is any possibility that the\nstring is not pure ASCII, it is necessary to ensure the encoding is valid\nUTF-8.\n\n.. warning::\n\n Implicit conversion assumes that a returned ``char *`` is null-terminated.\n If there is no null terminator a buffer overrun will occur.\n\nExplicit conversions\n--------------------\n\nIf some C++ code constructs a ``std::string`` that is not a UTF-8 string, one\ncan perform a explicit conversion and return a ``py::str`` object. Explicit\nconversion has the same overhead as implicit conversion.\n\n.. code-block:: c++\n\n // This uses the Python C API to convert Latin-1 to Unicode\n m.def(\"str_output\",\n []() {\n std::string s = \"Send your r\\xe9sum\\xe9 to Alice in HR\"; // Latin-1\n py::handle py_s = PyUnicode_DecodeLatin1(s.data(), s.length(), nullptr);\n if (!py_s) {\n throw py::error_already_set();\n }\n return py::reinterpret_steal(py_s);\n }\n );\n\n.. code-block:: pycon\n\n >>> str_output()\n 'Send your résumé to Alice in HR'\n\nThe `Python C API\n`_ provides\nseveral built-in codecs. Note that these all return *new* references, so\nuse :cpp:func:`reinterpret_steal` when converting them to a :cpp:class:`str`.\n\n\nOne could also use a third party encoding library such as libiconv to transcode\nto UTF-8.\n\nReturn C++ strings without conversion\n-------------------------------------\n\nIf the data in a C++ ``std::string`` does not represent text and should be\nreturned to Python as ``bytes``, then one can return the data as a\n``py::bytes`` object.\n\n.. code-block:: c++\n\n m.def(\"return_bytes\",\n []() {\n std::string s(\"\\xba\\xd0\\xba\\xd0\"); // Not valid UTF-8\n return py::bytes(s); // Return the data without transcoding\n }\n );\n\n.. code-block:: pycon\n\n >>> example.return_bytes()\n b'\\xba\\xd0\\xba\\xd0'\n\n\nNote the asymmetry: pybind11 will convert ``bytes`` to ``std::string`` without\nencoding, but cannot convert ``std::string`` back to ``bytes`` implicitly.\n\n.. code-block:: c++\n\n m.def(\"asymmetry\",\n [](std::string s) { // Accepts str or bytes from Python\n return s; // Looks harmless, but implicitly converts to str\n }\n );\n\n.. code-block:: pycon\n\n >>> isinstance(example.asymmetry(b\"have some bytes\"), str)\n True\n\n >>> example.asymmetry(b\"\\xba\\xd0\\xba\\xd0\") # invalid utf-8 as bytes\n UnicodeDecodeError: 'utf-8' codec can't decode byte 0xba in position 0: invalid start byte\n\n\nWide character strings\n======================\n\nWhen a Python ``str`` is passed to a C++ function expecting ``std::wstring``,\n``wchar_t*``, ``std::u16string`` or ``std::u32string``, the ``str`` will be\nencoded to UTF-16 or UTF-32 depending on how the C++ compiler implements each\ntype, in the platform's native endianness. When strings of these types are\nreturned, they are assumed to contain valid UTF-16 or UTF-32, and will be\ndecoded to Python ``str``.\n\n.. code-block:: c++\n\n #define UNICODE\n #include \n\n m.def(\"set_window_text\",\n [](HWND hwnd, std::wstring s) {\n // Call SetWindowText with null-terminated UTF-16 string\n ::SetWindowText(hwnd, s.c_str());\n }\n );\n m.def(\"get_window_text\",\n [](HWND hwnd) {\n const int buffer_size = ::GetWindowTextLength(hwnd) + 1;\n auto buffer = std::make_unique< wchar_t[] >(buffer_size);\n\n ::GetWindowText(hwnd, buffer.data(), buffer_size);\n\n std::wstring text(buffer.get());\n\n // wstring will be converted to Python str\n return text;\n }\n );\n\nStrings in multibyte encodings such as Shift-JIS must transcoded to a\nUTF-8/16/32 before being returned to Python.\n\n\nCharacter literals\n==================\n\nC++ functions that accept character literals as input will receive the first\ncharacter of a Python ``str`` as their input. If the string is longer than one\nUnicode character, trailing characters will be ignored.\n\nWhen a character literal is returned from C++ (such as a ``char`` or a\n``wchar_t``), it will be converted to a ``str`` that represents the single\ncharacter.\n\n.. code-block:: c++\n\n m.def(\"pass_char\", [](char c) { return c; });\n m.def(\"pass_wchar\", [](wchar_t w) { return w; });\n\n.. code-block:: pycon\n\n >>> example.pass_char(\"A\")\n 'A'\n\nWhile C++ will cast integers to character types (``char c = 0x65;``), pybind11\ndoes not convert Python integers to characters implicitly. The Python function\n``chr()`` can be used to convert integers to characters.\n\n.. code-block:: pycon\n\n >>> example.pass_char(0x65)\n TypeError\n\n >>> example.pass_char(chr(0x65))\n 'A'\n\nIf the desire is to work with an 8-bit integer, use ``int8_t`` or ``uint8_t``\nas the argument type.\n\nGrapheme clusters\n-----------------\n\nA single grapheme may be represented by two or more Unicode characters. For\nexample 'é' is usually represented as U+00E9 but can also be expressed as the\ncombining character sequence U+0065 U+0301 (that is, the letter 'e' followed by\na combining acute accent). The combining character will be lost if the\ntwo-character sequence is passed as an argument, even though it renders as a\nsingle grapheme.\n\n.. code-block:: pycon\n\n >>> example.pass_wchar(\"é\")\n 'é'\n\n >>> combining_e_acute = \"e\" + \"\\u0301\"\n\n >>> combining_e_acute\n 'é'\n\n >>> combining_e_acute == \"é\"\n False\n\n >>> example.pass_wchar(combining_e_acute)\n 'e'\n\nNormalizing combining characters before passing the character literal to C++\nmay resolve *some* of these issues:\n\n.. code-block:: pycon\n\n >>> example.pass_wchar(unicodedata.normalize(\"NFC\", combining_e_acute))\n 'é'\n\nIn some languages (Thai for example), there are `graphemes that cannot be\nexpressed as a single Unicode code point\n`_, so there is\nno way to capture them in a C++ character type.\n\n\nC++17 string views\n==================\n\nC++17 string views are automatically supported when compiling in C++17 mode.\nThey follow the same rules for encoding and decoding as the corresponding STL\nstring type (for example, a ``std::u16string_view`` argument will be passed\nUTF-16-encoded data, and a returned ``std::string_view`` will be decoded as\nUTF-8).\n\nReferences\n==========\n\n* `The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) `_\n* `C++ - Using STL Strings at Win32 API Boundaries `_\n" }, { "path": "docs/advanced/classes.rst", "content": "Classes\n#######\n\nThis section presents advanced binding code for classes and it is assumed\nthat you are already familiar with the basics from :doc:`/classes`.\n\n.. _overriding_virtuals:\n\nOverriding virtual functions in Python\n======================================\n\nSuppose that a C++ class or interface has a virtual function that we'd like\nto override from within Python (we'll focus on the class ``Animal``; ``Dog`` is\ngiven as a specific example of how one would do this with traditional C++\ncode).\n\n.. code-block:: cpp\n\n class Animal {\n public:\n virtual ~Animal() { }\n virtual std::string go(int n_times) = 0;\n };\n\n class Dog : public Animal {\n public:\n std::string go(int n_times) override {\n std::string result;\n for (int i=0; igo(3);\n }\n\nNormally, the binding code for these classes would look as follows:\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n py::class_(m, \"Animal\")\n .def(\"go\", &Animal::go);\n\n py::class_(m, \"Dog\")\n .def(py::init<>());\n\n m.def(\"call_go\", &call_go);\n }\n\nHowever, these bindings are impossible to extend: ``Animal`` is not\nconstructible, and we clearly require some kind of \"trampoline\" that\nredirects virtual calls back to Python.\n\nDefining a new type of ``Animal`` from within Python is possible but requires a\nhelper class that is defined as follows:\n\n.. code-block:: cpp\n\n class PyAnimal : public Animal, public py::trampoline_self_life_support {\n public:\n /* Inherit the constructors */\n using Animal::Animal;\n\n /* Trampoline (need one for each virtual function) */\n std::string go(int n_times) override {\n PYBIND11_OVERRIDE_PURE(\n std::string, /* Return type */\n Animal, /* Parent class */\n go, /* Name of function in C++ (must match Python name) */\n n_times /* Argument(s) */\n );\n }\n };\n\nThe ``py::trampoline_self_life_support`` base class is needed to ensure\nthat a ``std::unique_ptr`` can safely be passed between Python and C++. To\nhelp you steer clear of notorious pitfalls (e.g. inheritance slicing),\npybind11 enforces that trampoline classes inherit from\n``py::trampoline_self_life_support`` if used in in combination with\n``py::smart_holder``.\n\n.. note::\n For completeness, the base class has no effect if a holder other than\n ``py::smart_holder`` used, including the default ``std::unique_ptr``.\n To avoid confusion, pybind11 will fail to compile bindings that combine\n ``py::trampoline_self_life_support`` with a holder other than\n ``py::smart_holder``.\n\n Please think twice, though, before deciding to not use the safer\n ``py::smart_holder``. The pitfalls associated with avoiding it are very\n real, and the overhead for using it is very likely in the noise.\n\nThe macro :c:macro:`PYBIND11_OVERRIDE_PURE` should be used for pure virtual\nfunctions, and :c:macro:`PYBIND11_OVERRIDE` should be used for functions which have\na default implementation. There are also two alternate macros\n:c:macro:`PYBIND11_OVERRIDE_PURE_NAME` and :c:macro:`PYBIND11_OVERRIDE_NAME` which\ntake a string-valued name argument between the *Parent class* and *Name of the\nfunction* slots, which defines the name of function in Python. This is required\nwhen the C++ and Python versions of the\nfunction have different names, e.g. ``operator()`` vs ``__call__``.\n\nThe binding code also needs a few minor adaptations (highlighted):\n\n.. code-block:: cpp\n :emphasize-lines: 2,3\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n py::class_(m, \"Animal\")\n .def(py::init<>())\n .def(\"go\", &Animal::go);\n\n py::class_(m, \"Dog\")\n .def(py::init<>());\n\n m.def(\"call_go\", &call_go);\n }\n\nImportantly, pybind11 is made aware of the trampoline helper class by\nspecifying it as an extra template argument to ``py::class_``. (This can also\nbe combined with other template arguments such as a custom holder type; the\norder of template types does not matter). Following this, we are able to\ndefine a constructor as usual.\n\nBindings should be made against the actual class, not the trampoline helper class.\n\n.. code-block:: cpp\n :emphasize-lines: 3\n\n py::class_(m, \"Animal\");\n .def(py::init<>())\n .def(\"go\", &Animal::go); /* <--- DO NOT USE &PyAnimal::go HERE */\n\nNote, however, that the above is sufficient for allowing python classes to\nextend ``Animal``, but not ``Dog``: see :ref:`virtual_and_inheritance` for the\nnecessary steps required to providing proper overriding support for inherited\nclasses.\n\nThe Python session below shows how to override ``Animal::go`` and invoke it via\na virtual method call.\n\n.. code-block:: pycon\n\n >>> from example import *\n >>> d = Dog()\n >>> call_go(d)\n 'woof! woof! woof! '\n >>> class Cat(Animal):\n ... def go(self, n_times):\n ... return \"meow! \" * n_times\n ...\n >>> c = Cat()\n >>> call_go(c)\n 'meow! meow! meow! '\n\nIf you are defining a custom constructor in a derived Python class, you *must*\nensure that you explicitly call the bound C++ constructor using ``__init__``,\n*regardless* of whether it is a default constructor or not. Otherwise, the\nmemory for the C++ portion of the instance will be left uninitialized, which\nwill generally leave the C++ instance in an invalid state and cause undefined\nbehavior if the C++ instance is subsequently used.\n\n.. versionchanged:: 2.6\n The default pybind11 metaclass will throw a ``TypeError`` when it detects\n that ``__init__`` was not called by a derived class.\n\nHere is an example:\n\n.. code-block:: python\n\n class Dachshund(Dog):\n def __init__(self, name):\n Dog.__init__(self) # Without this, a TypeError is raised.\n self.name = name\n\n def bark(self):\n return \"yap!\"\n\nNote that a direct ``__init__`` constructor *should be called*, and ``super()``\nshould not be used. For simple cases of linear inheritance, ``super()``\nmay work, but once you begin mixing Python and C++ multiple inheritance,\nthings will fall apart due to differences between Python's MRO and C++'s\nmechanisms.\n\nPlease take a look at the :ref:`macro_notes` before using this feature.\n\n.. note::\n\n When the overridden type returns a reference or pointer to a type that\n pybind11 converts from Python (for example, numeric values, std::string,\n and other built-in value-converting types), there are some limitations to\n be aware of:\n\n - because in these cases there is no C++ variable to reference (the value\n is stored in the referenced Python variable), pybind11 provides one in\n the PYBIND11_OVERRIDE macros (when needed) with static storage duration.\n Note that this means that invoking the overridden method on *any*\n instance will change the referenced value stored in *all* instances of\n that type.\n\n - Attempts to modify a non-const reference will not have the desired\n effect: it will change only the static cache variable, but this change\n will not propagate to underlying Python instance, and the change will be\n replaced the next time the override is invoked.\n\n.. warning::\n\n The :c:macro:`PYBIND11_OVERRIDE` and accompanying macros used to be called\n ``PYBIND11_OVERLOAD`` up until pybind11 v2.5.0, and :func:`get_override`\n used to be called ``get_overload``. This naming was corrected and the older\n macro and function names may soon be deprecated, in order to reduce\n confusion with overloaded functions and methods and ``py::overload_cast``\n (see :ref:`classes`).\n\n.. seealso::\n\n The file :file:`tests/test_virtual_functions.cpp` contains a complete\n example that demonstrates how to override virtual functions using pybind11\n in more detail.\n\n.. _virtual_and_inheritance:\n\nCombining virtual functions and inheritance\n===========================================\n\nWhen combining virtual methods with inheritance, you need to be sure to provide\nan override for each method for which you want to allow overrides from derived\npython classes. For example, suppose we extend the above ``Animal``/``Dog``\nexample as follows:\n\n.. code-block:: cpp\n\n class Animal {\n public:\n virtual std::string go(int n_times) = 0;\n virtual std::string name() { return \"unknown\"; }\n };\n class Dog : public Animal {\n public:\n std::string go(int n_times) override {\n std::string result;\n for (int i=0; i\n class PyAnimal : public AnimalBase, public py::trampoline_self_life_support {\n public:\n using AnimalBase::AnimalBase; // Inherit constructors\n std::string go(int n_times) override { PYBIND11_OVERRIDE_PURE(std::string, AnimalBase, go, n_times); }\n std::string name() override { PYBIND11_OVERRIDE(std::string, AnimalBase, name, ); }\n };\n template \n class PyDog : public PyAnimal, public py::trampoline_self_life_support {\n public:\n using PyAnimal::PyAnimal; // Inherit constructors\n // Override PyAnimal's pure virtual go() with a non-pure one:\n std::string go(int n_times) override { PYBIND11_OVERRIDE(std::string, DogBase, go, n_times); }\n std::string bark() override { PYBIND11_OVERRIDE(std::string, DogBase, bark, ); }\n };\n\nThis technique has the advantage of requiring just one trampoline method to be\ndeclared per virtual method and pure virtual method override. It does,\nhowever, require the compiler to generate at least as many methods (and\npossibly more, if both pure virtual and overridden pure virtual methods are\nexposed, as above).\n\nThe classes are then registered with pybind11 using:\n\n.. code-block:: cpp\n\n py::class_, py::smart_holder> animal(m, \"Animal\");\n py::class_, py::smart_holder> dog(m, \"Dog\");\n py::class_, py::smart_holder> husky(m, \"Husky\");\n // ... add animal, dog, husky definitions\n\nNote that ``Husky`` did not require a dedicated trampoline template class at\nall, since it neither declares any new virtual methods nor provides any pure\nvirtual method implementations.\n\nWith either the repeated-virtuals or templated trampoline methods in place, you\ncan now create a python class that inherits from ``Dog``:\n\n.. code-block:: python\n\n class ShihTzu(Dog):\n def bark(self):\n return \"yip!\"\n\n.. seealso::\n\n See the file :file:`tests/test_virtual_functions.cpp` for complete examples\n using both the duplication and templated trampoline approaches.\n\n.. _extended_aliases:\n\nExtended trampoline class functionality\n=======================================\n\n.. _extended_class_functionality_forced_trampoline:\n\nForced trampoline class initialisation\n--------------------------------------\nThe trampoline classes described in the previous sections are, by default, only\ninitialized when needed. More specifically, they are initialized when a python\nclass actually inherits from a registered type (instead of merely creating an\ninstance of the registered type), or when a registered constructor is only\nvalid for the trampoline class but not the registered class. This is primarily\nfor performance reasons: when the trampoline class is not needed for anything\nexcept virtual method dispatching, not initializing the trampoline class\nimproves performance by avoiding needing to do a run-time check to see if the\ninheriting python instance has an overridden method.\n\nSometimes, however, it is useful to always initialize a trampoline class as an\nintermediate class that does more than just handle virtual method dispatching.\nFor example, such a class might perform extra class initialization, extra\ndestruction operations, and might define new members and methods to enable a\nmore python-like interface to a class.\n\nIn order to tell pybind11 that it should *always* initialize the trampoline\nclass when creating new instances of a type, the class constructors should be\ndeclared using ``py::init_alias()`` instead of the usual\n``py::init()``. This forces construction via the trampoline class,\nensuring member initialization and (eventual) destruction.\n\n.. seealso::\n\n See the file :file:`tests/test_virtual_functions.cpp` for complete examples\n showing both normal and forced trampoline instantiation.\n\nDifferent method signatures\n---------------------------\nThe macro's introduced in :ref:`overriding_virtuals` cover most of the standard\nuse cases when exposing C++ classes to Python. Sometimes it is hard or unwieldy\nto create a direct one-on-one mapping between the arguments and method return\ntype.\n\nAn example would be when the C++ signature contains output arguments using\nreferences (See also :ref:`faq_reference_arguments`). Another way of solving\nthis is to use the method body of the trampoline class to do conversions to the\ninput and return of the Python method.\n\nThe main building block to do so is the :func:`get_override`, this function\nallows retrieving a method implemented in Python from within the trampoline's\nmethods. Consider for example a C++ method which has the signature\n``bool myMethod(int32_t& value)``, where the return indicates whether\nsomething should be done with the ``value``. This can be made convenient on the\nPython side by allowing the Python function to return ``None`` or an ``int``:\n\n.. code-block:: cpp\n\n bool MyClass::myMethod(int32_t& value)\n {\n pybind11::gil_scoped_acquire gil; // Acquire the GIL while in this scope.\n // Try to look up the overridden method on the Python side.\n pybind11::function override = pybind11::get_override(this, \"myMethod\");\n if (override) { // method is found\n auto obj = override(value); // Call the Python function.\n if (py::isinstance(obj)) { // check if it returned a Python integer type\n value = obj.cast(); // Cast it and assign it to the value.\n return true; // Return true; value should be used.\n } else {\n return false; // Python returned none, return false.\n }\n }\n return false; // Alternatively return MyClass::myMethod(value);\n }\n\nAvoiding Inheritance Slicing and ``std::weak_ptr`` surprises\n------------------------------------------------------------\n\nWhen working with classes that use virtual functions and are subclassed\nin Python, special care must be taken when converting Python objects to\n``std::shared_ptr``. Depending on whether the class uses a plain\n``std::shared_ptr`` holder or ``py::smart_holder``, the resulting\n``shared_ptr`` may either allow inheritance slicing or lead to potentially\nsurprising behavior when constructing ``std::weak_ptr`` instances.\n\nThis section explains how ``std::shared_ptr`` and ``py::smart_holder`` manage\nobject lifetimes differently, how these differences affect trampoline-derived\nobjects, and what options are available to achieve the situation-specific\ndesired behavior.\n\nWhen using ``std::shared_ptr`` as the holder type, converting a Python object\nto a ``std::shared_ptr`` (e.g., ``obj.cast>()``, or simply\npassing the Python object as an argument to a ``.def()``-ed function) returns\na ``shared_ptr`` that shares ownership with the original ``class_`` holder,\nusually preserving object lifetime. However, for Python classes that derive from\na trampoline, if the Python object is destroyed, only the base C++ object may\nremain alive, leading to inheritance slicing\n(see `#1333 `_).\n\nIn contrast, with ``py::smart_holder``, converting a Python object to\na ``std::shared_ptr`` returns a new ``shared_ptr`` with an independent\ncontrol block that keeps the derived Python object alive. This avoids\ninheritance slicing but can lead to unintended behavior when creating\n``std::weak_ptr`` instances\n(see `#5623 `_).\n\nIf it is necessary to obtain a ``std::weak_ptr`` that shares the control block\nwith the ``smart_holder``—at the cost of reintroducing potential inheritance\nslicing—you can use ``py::potentially_slicing_weak_ptr(obj)``.\n\nWhen precise lifetime management of derived Python objects is important,\nusing a Python-side ``weakref`` is the most reliable approach, as it avoids\nboth inheritance slicing and unintended interactions with ``std::weak_ptr``\nsemantics in C++.\n\n.. seealso::\n\n * :func:`potentially_slicing_weak_ptr` C++ documentation\n * :file:`tests/test_potentially_slicing_weak_ptr.cpp`\n\n\n.. _custom_constructors:\n\nCustom constructors\n===================\n\nThe syntax for binding constructors was previously introduced, but it only\nworks when a constructor of the appropriate arguments actually exists on the\nC++ side. To extend this to more general cases, pybind11 makes it possible\nto bind factory functions as constructors. For example, suppose you have a\nclass like this:\n\n.. code-block:: cpp\n\n class Example {\n private:\n Example(int); // private constructor\n public:\n // Factory function:\n static Example create(int a) { return Example(a); }\n };\n\n py::class_(m, \"Example\")\n .def(py::init(&Example::create));\n\nWhile it is possible to create a straightforward binding of the static\n``create`` method, it may sometimes be preferable to expose it as a constructor\non the Python side. This can be accomplished by calling ``.def(py::init(...))``\nwith the function reference returning the new instance passed as an argument.\nIt is also possible to use this approach to bind a function returning a new\ninstance by raw pointer or by the holder (e.g. ``std::unique_ptr``).\n\nThe following example shows the different approaches:\n\n.. code-block:: cpp\n\n class Example {\n private:\n Example(int); // private constructor\n public:\n // Factory function - returned by value:\n static Example create(int a) { return Example(a); }\n\n // These constructors are publicly callable:\n Example(double);\n Example(int, int);\n Example(std::string);\n };\n\n py::class_(m, \"Example\")\n // Bind the factory function as a constructor:\n .def(py::init(&Example::create))\n // Bind a lambda function returning a pointer wrapped in a holder:\n .def(py::init([](std::string arg) {\n return std::unique_ptr(new Example(arg));\n }))\n // Return a raw pointer:\n .def(py::init([](int a, int b) { return new Example(a, b); }))\n // You can mix the above with regular C++ constructor bindings as well:\n .def(py::init())\n ;\n\nWhen the constructor is invoked from Python, pybind11 will call the factory\nfunction and store the resulting C++ instance in the Python instance.\n\nWhen combining factory functions constructors with :ref:`virtual function\ntrampolines ` there are two approaches. The first is to\nadd a constructor to the alias class that takes a base value by\nrvalue-reference. If such a constructor is available, it will be used to\nconstruct an alias instance from the value returned by the factory function.\nThe second option is to provide two factory functions to ``py::init()``: the\nfirst will be invoked when no alias class is required (i.e. when the class is\nbeing used but not inherited from in Python), and the second will be invoked\nwhen an alias is required.\n\nYou can also specify a single factory function that always returns an alias\ninstance: this will result in behaviour similar to ``py::init_alias<...>()``,\nas described in the :ref:`extended trampoline class documentation\n`.\n\nThe following example shows the different factory approaches for a class with\nan alias:\n\n.. code-block:: cpp\n\n #include \n class Example {\n public:\n // ...\n virtual ~Example() = default;\n };\n class PyExample : public Example, public py::trampoline_self_life_support {\n public:\n using Example::Example;\n PyExample(Example &&base) : Example(std::move(base)) {}\n };\n py::class_(m, \"Example\")\n // Returns an Example pointer. If a PyExample is needed, the Example\n // instance will be moved via the extra constructor in PyExample, above.\n .def(py::init([]() { return new Example(); }))\n // Two callbacks:\n .def(py::init([]() { return new Example(); } /* no alias needed */,\n []() { return new PyExample(); } /* alias needed */))\n // *Always* returns an alias instance (like py::init_alias<>())\n .def(py::init([]() { return new PyExample(); }))\n ;\n\nBrace initialization\n--------------------\n\n``pybind11::init<>`` internally uses C++11 brace initialization to call the\nconstructor of the target class. This means that it can be used to bind\n*implicit* constructors as well:\n\n.. code-block:: cpp\n\n struct Aggregate {\n int a;\n std::string b;\n };\n\n py::class_(m, \"Aggregate\")\n .def(py::init());\n\n.. note::\n\n Note that brace initialization preferentially invokes constructor overloads\n taking a ``std::initializer_list``. In the rare event that this causes an\n issue, you can work around it by using ``py::init(...)`` with a lambda\n function that constructs the new object as desired.\n\n.. _classes_with_non_public_destructors:\n\nNon-public destructors\n======================\n\nIf a class has a private or protected destructor (as might e.g. be the case in\na singleton pattern), a compile error will occur when creating bindings via\npybind11. The underlying issue is that the ``std::unique_ptr`` holder type that\nis responsible for managing the lifetime of instances will reference the\ndestructor even if no deallocations ever take place. In order to expose classes\nwith private or protected destructors, it is possible to override the holder\ntype via a holder type argument to ``py::class_``. Pybind11 provides a helper\nclass ``py::nodelete`` that disables any destructor invocations. In this case,\nit is crucial that instances are deallocated on the C++ side to avoid memory\nleaks.\n\n.. code-block:: cpp\n\n /* ... definition ... */\n\n class MyClass {\n private:\n ~MyClass() { }\n };\n\n /* ... binding code ... */\n\n py::class_>(m, \"MyClass\")\n .def(py::init<>())\n\n.. _destructors_that_call_python:\n\nDestructors that call Python\n============================\n\nIf a Python function is invoked from a C++ destructor, an exception may be thrown\nof type :class:`error_already_set`. If this error is thrown out of a class destructor,\n``std::terminate()`` will be called, terminating the process. Class destructors\nmust catch all exceptions of type :class:`error_already_set` to discard the Python\nexception using :func:`error_already_set::discard_as_unraisable`.\n\nEvery Python function should be treated as *possibly throwing*. When a Python generator\nstops yielding items, Python will throw a ``StopIteration`` exception, which can pass\nthough C++ destructors if the generator's stack frame holds the last reference to C++\nobjects.\n\nFor more information, see :ref:`the documentation on exceptions `.\n\n.. code-block:: cpp\n\n class MyClass {\n public:\n ~MyClass() {\n try {\n py::print(\"Even printing is dangerous in a destructor\");\n py::exec(\"raise ValueError('This is an unraisable exception')\");\n } catch (py::error_already_set &e) {\n // error_context should be information about where/why the occurred,\n // e.g. use __func__ to get the name of the current function\n e.discard_as_unraisable(__func__);\n }\n }\n };\n\n.. note::\n\n pybind11 does not support C++ destructors marked ``noexcept(false)``.\n\n.. versionadded:: 2.6\n\n.. _implicit_conversions:\n\nImplicit conversions\n====================\n\nSuppose that instances of two types ``A`` and ``B`` are used in a project, and\nthat an ``A`` can easily be converted into an instance of type ``B`` (examples of this\ncould be a fixed and an arbitrary precision number type).\n\n.. code-block:: cpp\n\n py::class_(m, \"A\")\n /// ... members ...\n\n py::class_(m, \"B\")\n .def(py::init())\n /// ... members ...\n\n m.def(\"func\",\n [](const B &) { /* .... */ }\n );\n\nTo invoke the function ``func`` using a variable ``a`` containing an ``A``\ninstance, we'd have to write ``func(B(a))`` in Python. On the other hand, C++\nwill automatically apply an implicit type conversion, which makes it possible\nto directly write ``func(a)``.\n\nIn this situation (i.e. where ``B`` has a constructor that converts from\n``A``), the following statement enables similar implicit conversions on the\nPython side:\n\n.. code-block:: cpp\n\n py::implicitly_convertible();\n\n.. note::\n\n Implicit conversions from ``A`` to ``B`` only work when ``B`` is a custom\n data type that is exposed to Python via pybind11.\n\n To prevent runaway recursion, implicit conversions are non-reentrant: an\n implicit conversion invoked as part of another implicit conversion of the\n same type (i.e. from ``A`` to ``B``) will fail.\n\n.. _static_properties:\n\nStatic properties\n=================\n\nThe section on :ref:`properties` discussed the creation of instance properties\nthat are implemented in terms of C++ getters and setters.\n\nStatic properties can also be created in a similar way to expose getters and\nsetters of static class attributes. Note that the implicit ``self`` argument\nalso exists in this case and is used to pass the Python ``type`` subclass\ninstance. This parameter will often not be needed by the C++ side, and the\nfollowing example illustrates how to instantiate a lambda getter function\nthat ignores it:\n\n.. code-block:: cpp\n\n py::class_(m, \"Foo\")\n .def_property_readonly_static(\"foo\", [](py::object /* self */) { return Foo(); });\n\nOperator overloading\n====================\n\nSuppose that we're given the following ``Vector2`` class with a vector addition\nand scalar multiplication operation, all implemented using overloaded operators\nin C++.\n\n.. code-block:: cpp\n\n class Vector2 {\n public:\n Vector2(float x, float y) : x(x), y(y) { }\n\n Vector2 operator+(const Vector2 &v) const { return Vector2(x + v.x, y + v.y); }\n Vector2 operator*(float value) const { return Vector2(x * value, y * value); }\n Vector2& operator+=(const Vector2 &v) { x += v.x; y += v.y; return *this; }\n Vector2& operator*=(float v) { x *= v; y *= v; return *this; }\n\n friend Vector2 operator*(float f, const Vector2 &v) {\n return Vector2(f * v.x, f * v.y);\n }\n\n std::string toString() const {\n return \"[\" + std::to_string(x) + \", \" + std::to_string(y) + \"]\";\n }\n private:\n float x, y;\n };\n\nThe following snippet shows how the above operators can be conveniently exposed\nto Python.\n\n.. code-block:: cpp\n\n #include \n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n py::class_(m, \"Vector2\")\n .def(py::init())\n .def(py::self + py::self)\n .def(py::self += py::self)\n .def(py::self *= float())\n .def(float() * py::self)\n .def(py::self * float())\n .def(-py::self)\n .def(\"__repr__\", &Vector2::toString);\n }\n\nNote that a line like\n\n.. code-block:: cpp\n\n .def(py::self * float())\n\nis really just short hand notation for\n\n.. code-block:: cpp\n\n .def(\"__mul__\", [](const Vector2 &a, float b) {\n return a * b;\n }, py::is_operator())\n\nThis can be useful for exposing additional operators that don't exist on the\nC++ side, or to perform other types of customization. The ``py::is_operator``\nflag marker is needed to inform pybind11 that this is an operator, which\nreturns ``NotImplemented`` when invoked with incompatible arguments rather than\nthrowing a type error.\n\n.. note::\n\n To use the more convenient ``py::self`` notation, the additional\n header file :file:`pybind11/operators.h` must be included.\n\n.. seealso::\n\n The file :file:`tests/test_operator_overloading.cpp` contains a\n complete example that demonstrates how to work with overloaded operators in\n more detail.\n\n.. _pickling:\n\nPickling support\n================\n\nPython's ``pickle`` module provides a powerful facility to serialize and\nde-serialize a Python object graph into a binary data stream. To pickle and\nunpickle C++ classes using pybind11, a ``py::pickle()`` definition must be\nprovided. Suppose the class in question has the following signature:\n\n.. code-block:: cpp\n\n class Pickleable {\n public:\n Pickleable(const std::string &value) : m_value(value) { }\n const std::string &value() const { return m_value; }\n\n void setExtra(int extra) { m_extra = extra; }\n int extra() const { return m_extra; }\n private:\n std::string m_value;\n int m_extra = 0;\n };\n\nPickling support in Python is enabled by defining the ``__setstate__`` and\n``__getstate__`` methods [#f3]_. For pybind11 classes, use ``py::pickle()``\nto bind these two functions:\n\n.. code-block:: cpp\n\n py::class_(m, \"Pickleable\")\n .def(py::init())\n .def(\"value\", &Pickleable::value)\n .def(\"extra\", &Pickleable::extra)\n .def(\"setExtra\", &Pickleable::setExtra)\n .def(py::pickle(\n [](const Pickleable &p) { // __getstate__\n /* Return a tuple that fully encodes the state of the object */\n return py::make_tuple(p.value(), p.extra());\n },\n [](py::tuple t) { // __setstate__\n if (t.size() != 2)\n throw std::runtime_error(\"Invalid state!\");\n\n /* Create a new C++ instance */\n Pickleable p(t[0].cast());\n\n /* Assign any additional state */\n p.setExtra(t[1].cast());\n\n return p;\n }\n ));\n\nThe ``__setstate__`` part of the ``py::pickle()`` definition follows the same\nrules as the single-argument version of ``py::init()``. The return type can be\na value, pointer or holder type. See :ref:`custom_constructors` for details.\n\nAn instance can now be pickled as follows:\n\n.. code-block:: python\n\n import pickle\n\n p = Pickleable(\"test_value\")\n p.setExtra(15)\n data = pickle.dumps(p)\n\n\n.. note::\n If given, the second argument to ``dumps`` must be 2 or larger - 0 and 1 are\n not supported. Newer versions are also fine; for instance, specify ``-1`` to\n always use the latest available version. Beware: failure to follow these\n instructions will cause important pybind11 memory allocation routines to be\n skipped during unpickling, which will likely lead to memory corruption\n and/or segmentation faults.\n\n.. seealso::\n\n The file :file:`tests/test_pickling.cpp` contains a complete example\n that demonstrates how to pickle and unpickle types using pybind11 in more\n detail.\n\n.. [#f3] http://docs.python.org/3/library/pickle.html#pickling-class-instances\n\nDeepcopy support\n================\n\nPython normally uses references in assignments. Sometimes a real copy is needed\nto prevent changing all copies. The ``copy`` module [#f5]_ provides these\ncapabilities.\n\nA class with pickle support is automatically also (deep)copy\ncompatible. However, performance can be improved by adding custom\n``__copy__`` and ``__deepcopy__`` methods.\n\nFor simple classes (deep)copy can be enabled by using the copy constructor,\nwhich should look as follows:\n\n.. code-block:: cpp\n\n py::class_(m, \"Copyable\")\n .def(\"__copy__\", [](const Copyable &self) {\n return Copyable(self);\n })\n .def(\"__deepcopy__\", [](const Copyable &self, py::dict) {\n return Copyable(self);\n }, \"memo\"_a);\n\n.. note::\n\n Dynamic attributes will not be copied in this example.\n\n.. [#f5] https://docs.python.org/3/library/copy.html\n\nMultiple Inheritance\n====================\n\npybind11 can create bindings for types that derive from multiple base types\n(aka. *multiple inheritance*). To do so, specify all bases in the template\narguments of the ``py::class_`` declaration:\n\n.. code-block:: cpp\n\n py::class_(m, \"MyType\")\n ...\n\nThe base types can be specified in arbitrary order, and they can even be\ninterspersed with alias types and holder types (discussed earlier in this\ndocument)---pybind11 will automatically find out which is which. The only\nrequirement is that the first template argument is the type to be declared.\n\nIt is also permitted to inherit multiply from exported C++ classes in Python,\nas well as inheriting from multiple Python and/or pybind11-exported classes.\n\nThere is one caveat regarding the implementation of this feature:\n\nWhen only one base type is specified for a C++ type that actually has multiple\nbases, pybind11 will assume that it does not participate in multiple\ninheritance, which can lead to undefined behavior. In such cases, add the tag\n``multiple_inheritance`` to the class constructor:\n\n.. code-block:: cpp\n\n py::class_(m, \"MyType\", py::multiple_inheritance());\n\nThe tag is redundant and does not need to be specified when multiple base types\nare listed.\n\n.. _module_local:\n\nModule-local class bindings\n===========================\n\nWhen creating a binding for a class, pybind11 by default makes that binding\n\"global\" across modules. What this means is that instances whose type is\ndefined with a ``py::class_`` statement in one module can be passed to or\nreturned from a function defined in any other module that is \"ABI compatible\"\nwith the first, i.e., that was built with sufficiently similar versions of\npybind11 and of the C++ compiler and C++ standard library. The internal data\nstructures that pybind11 uses to keep track of its types and instances are\nshared just as they would be if everything were in the same module.\nFor example, this allows the following:\n\n.. code-block:: cpp\n\n // In the module1.cpp binding code for module1:\n py::class_(m, \"Pet\")\n .def(py::init())\n .def_readonly(\"name\", &Pet::name);\n\n.. code-block:: cpp\n\n // In the module2.cpp binding code for module2:\n m.def(\"create_pet\", [](std::string name) { return new Pet(name); });\n\n.. code-block:: pycon\n\n >>> from module1 import Pet\n >>> from module2 import create_pet\n >>> pet1 = Pet(\"Kitty\")\n >>> pet2 = create_pet(\"Doggy\")\n >>> pet2.name()\n 'Doggy'\n\nWhen writing binding code for a library, this is usually desirable: this\nallows, for example, splitting up a complex library into multiple Python\nmodules.\n\nIn some cases, however, this can cause conflicts. For example, suppose two\nunrelated modules make use of an external C++ library and each provide custom\nbindings for one of that library's classes. This will result in an error when\na Python program attempts to import both modules (directly or indirectly)\nbecause of conflicting definitions on the external type:\n\n.. code-block:: cpp\n\n // dogs.cpp\n\n // Binding for external library class:\n py::class_(m, \"Pet\")\n .def(\"name\", &pets::Pet::name);\n\n // Binding for local extension class:\n py::class_(m, \"Dog\")\n .def(py::init());\n\n.. code-block:: cpp\n\n // cats.cpp, in a completely separate project from the above dogs.cpp.\n\n // Binding for external library class:\n py::class_(m, \"Pet\")\n .def(\"get_name\", &pets::Pet::name);\n\n // Binding for local extending class:\n py::class_(m, \"Cat\")\n .def(py::init());\n\n.. code-block:: pycon\n\n >>> import cats\n >>> import dogs\n Traceback (most recent call last):\n File \"\", line 1, in \n ImportError: generic_type: type \"Pet\" is already registered!\n\nTo get around this, you can tell pybind11 to keep the external class binding\nlocalized to the module by passing the ``py::module_local()`` attribute into\nthe ``py::class_`` constructor:\n\n.. code-block:: cpp\n\n // Pet binding in dogs.cpp:\n py::class_(m, \"Pet\", py::module_local())\n .def(\"name\", &pets::Pet::name);\n\n.. code-block:: cpp\n\n // Pet binding in cats.cpp:\n py::class_(m, \"Pet\", py::module_local())\n .def(\"get_name\", &pets::Pet::name);\n\nThis makes the Python-side ``dogs.Pet`` and ``cats.Pet`` into distinct classes,\navoiding the conflict and allowing both modules to be loaded. C++ code in the\n``dogs`` module that casts or returns a ``Pet`` instance will result in a\n``dogs.Pet`` Python instance, while C++ code in the ``cats`` module will result\nin a ``cats.Pet`` Python instance.\n\nThis does come with two caveats, however: First, external modules cannot return\nor cast a ``Pet`` instance to Python (unless they also provide their own local\nbindings). Second, from the Python point of view they are two distinct classes.\n\nNote that the locality only applies in the C++ -> Python direction. When\npassing such a ``py::module_local`` type into a C++ function, the module-local\nclasses are still considered. This means that if the following function is\nadded to any module (including but not limited to the ``cats`` and ``dogs``\nmodules above) it will be callable with either a ``dogs.Pet`` or ``cats.Pet``\nargument:\n\n.. code-block:: cpp\n\n m.def(\"pet_name\", [](const pets::Pet &pet) { return pet.name(); });\n\nFor example, suppose the above function is added to each of ``cats.cpp``,\n``dogs.cpp`` and ``frogs.cpp`` (where ``frogs.cpp`` is some other module that\ndoes *not* bind ``Pets`` at all).\n\n.. code-block:: pycon\n\n >>> import cats, dogs, frogs # No error because of the added py::module_local()\n >>> mycat, mydog = cats.Cat(\"Fluffy\"), dogs.Dog(\"Rover\")\n >>> (cats.pet_name(mycat), dogs.pet_name(mydog))\n ('Fluffy', 'Rover')\n >>> (cats.pet_name(mydog), dogs.pet_name(mycat), frogs.pet_name(mycat))\n ('Rover', 'Fluffy', 'Fluffy')\n\nIt is possible to use ``py::module_local()`` registrations in one module even\nif another module registers the same type globally: within the module with the\nmodule-local definition, all C++ instances will be cast to the associated bound\nPython type. In other modules any such values are converted to the global\nPython type created elsewhere.\n\n.. note::\n\n STL bindings (as provided via the optional :file:`pybind11/stl_bind.h`\n header) apply ``py::module_local`` by default when the bound type might\n conflict with other modules; see :ref:`stl_bind` for details.\n\n.. note::\n\n The localization of the bound types is actually tied to the shared object\n or binary generated by the compiler/linker. For typical modules created\n with ``PYBIND11_MODULE()``, this distinction is not significant. It is\n possible, however, when :ref:`embedding` to embed multiple modules in the\n same binary (see :ref:`embedding_modules`). In such a case, the\n localization will apply across all embedded modules within the same binary.\n\n.. seealso::\n\n The file :file:`tests/test_local_bindings.cpp` contains additional examples\n that demonstrate how ``py::module_local()`` works.\n\nBinding protected member functions\n==================================\n\nIt's normally not possible to expose ``protected`` member functions to Python:\n\n.. code-block:: cpp\n\n class A {\n protected:\n int foo() const { return 42; }\n };\n\n py::class_(m, \"A\")\n .def(\"foo\", &A::foo); // error: 'foo' is a protected member of 'A'\n\nOn one hand, this is good because non-``public`` members aren't meant to be\naccessed from the outside. But we may want to make use of ``protected``\nfunctions in derived Python classes.\n\nThe following pattern makes this possible:\n\n.. code-block:: cpp\n\n class A {\n protected:\n int foo() const { return 42; }\n };\n\n class Publicist : public A { // helper type for exposing protected functions\n public:\n using A::foo; // inherited with different access modifier\n };\n\n py::class_(m, \"A\") // bind the primary class\n .def(\"foo\", &Publicist::foo); // expose protected methods via the publicist\n\nThis works because ``&Publicist::foo`` is exactly the same function as\n``&A::foo`` (same signature and address), just with a different access\nmodifier. The only purpose of the ``Publicist`` helper class is to make\nthe function name ``public``.\n\nIf the intent is to expose ``protected`` ``virtual`` functions which can be\noverridden in Python, the publicist pattern can be combined with the previously\ndescribed trampoline:\n\n.. code-block:: cpp\n\n class A {\n public:\n virtual ~A() = default;\n\n protected:\n virtual int foo() const { return 42; }\n };\n\n class Trampoline : public A, public py::trampoline_self_life_support {\n public:\n int foo() const override { PYBIND11_OVERRIDE(int, A, foo, ); }\n };\n\n class Publicist : public A {\n public:\n using A::foo;\n };\n\n py::class_(m, \"A\") // <-- `Trampoline` here\n .def(\"foo\", &Publicist::foo); // <-- `Publicist` here, not `Trampoline`!\n\nBinding final classes\n=====================\n\nSome classes may not be appropriate to inherit from. In C++11, classes can\nuse the ``final`` specifier to ensure that a class cannot be inherited from.\nThe ``py::is_final`` attribute can be used to ensure that Python classes\ncannot inherit from a specified type. The underlying C++ type does not need\nto be declared final.\n\n.. code-block:: cpp\n\n class IsFinal final {};\n\n py::class_(m, \"IsFinal\", py::is_final());\n\nWhen you try to inherit from such a class in Python, you will now get this\nerror:\n\n.. code-block:: pycon\n\n >>> class PyFinalChild(IsFinal):\n ... pass\n ...\n TypeError: type 'IsFinal' is not an acceptable base type\n\n.. note:: This attribute is currently ignored on PyPy\n\n.. versionadded:: 2.6\n\nBinding classes with template parameters\n========================================\n\npybind11 can also wrap classes that have template parameters. Consider these classes:\n\n.. code-block:: cpp\n\n struct Cat {};\n struct Dog {};\n\n template \n struct Cage {\n Cage(PetType& pet);\n PetType& get();\n };\n\nC++ templates may only be instantiated at compile time, so pybind11 can only\nwrap instantiated templated classes. You cannot wrap a non-instantiated template:\n\n.. code-block:: cpp\n\n // BROKEN (this will not compile)\n py::class_(m, \"Cage\");\n .def(\"get\", &Cage::get);\n\nYou must explicitly specify each template/type combination that you want to\nwrap separately.\n\n.. code-block:: cpp\n\n // ok\n py::class_>(m, \"CatCage\")\n .def(\"get\", &Cage::get);\n\n // ok\n py::class_>(m, \"DogCage\")\n .def(\"get\", &Cage::get);\n\nIf your class methods have template parameters you can wrap those as well,\nbut once again each instantiation must be explicitly specified:\n\n.. code-block:: cpp\n\n typename \n struct MyClass {\n template \n T fn(V v);\n };\n\n py::class_>(m, \"MyClassT\")\n .def(\"fn\", &MyClass::fn);\n\nCustom automatic downcasters\n============================\n\nAs explained in :ref:`inheritance`, pybind11 comes with built-in\nunderstanding of the dynamic type of polymorphic objects in C++; that\nis, returning a Pet to Python produces a Python object that knows it's\nwrapping a Dog, if Pet has virtual methods and pybind11 knows about\nDog and this Pet is in fact a Dog. Sometimes, you might want to\nprovide this automatic downcasting behavior when creating bindings for\na class hierarchy that does not use standard C++ polymorphism, such as\nLLVM [#f4]_. As long as there's some way to determine at runtime\nwhether a downcast is safe, you can proceed by specializing the\n``pybind11::polymorphic_type_hook`` template:\n\n.. code-block:: cpp\n\n enum class PetKind { Cat, Dog, Zebra };\n struct Pet { // Not polymorphic: has no virtual methods\n const PetKind kind;\n int age = 0;\n protected:\n Pet(PetKind _kind) : kind(_kind) {}\n };\n struct Dog : Pet {\n Dog() : Pet(PetKind::Dog) {}\n std::string sound = \"woof!\";\n std::string bark() const { return sound; }\n };\n\n namespace PYBIND11_NAMESPACE {\n template<> struct polymorphic_type_hook {\n static const void *get(const Pet *src, const std::type_info*& type) {\n // note that src may be nullptr\n if (src && src->kind == PetKind::Dog) {\n type = &typeid(Dog);\n return static_cast(src);\n }\n return src;\n }\n };\n } // namespace PYBIND11_NAMESPACE\n\nWhen pybind11 wants to convert a C++ pointer of type ``Base*`` to a\nPython object, it calls ``polymorphic_type_hook::get()`` to\ndetermine if a downcast is possible. The ``get()`` function should use\nwhatever runtime information is available to determine if its ``src``\nparameter is in fact an instance of some class ``Derived`` that\ninherits from ``Base``. If it finds such a ``Derived``, it sets ``type\n= &typeid(Derived)`` and returns a pointer to the ``Derived`` object\nthat contains ``src``. Otherwise, it just returns ``src``, leaving\n``type`` at its default value of nullptr. If you set ``type`` to a\ntype that pybind11 doesn't know about, no downcasting will occur, and\nthe original ``src`` pointer will be used with its static type\n``Base*``.\n\nIt is critical that the returned pointer and ``type`` argument of\n``get()`` agree with each other: if ``type`` is set to something\nnon-null, the returned pointer must point to the start of an object\nwhose type is ``type``. If the hierarchy being exposed uses only\nsingle inheritance, a simple ``return src;`` will achieve this just\nfine, but in the general case, you must cast ``src`` to the\nappropriate derived-class pointer (e.g. using\n``static_cast(src)``) before allowing it to be returned as a\n``void*``.\n\n.. [#f4] https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html\n\n.. note::\n\n pybind11's standard support for downcasting objects whose types\n have virtual methods is implemented using\n ``polymorphic_type_hook`` too, using the standard C++ ability to\n determine the most-derived type of a polymorphic object using\n ``typeid()`` and to cast a base pointer to that most-derived type\n (even if you don't know what it is) using ``dynamic_cast``.\n\n.. seealso::\n\n The file :file:`tests/test_tagbased_polymorphic.cpp` contains a\n more complete example, including a demonstration of how to provide\n automatic downcasting for an entire class hierarchy without\n writing one get() function for each class.\n\nAccessing the type object\n=========================\n\nYou can get the type object from a C++ class that has already been registered using:\n\n.. code-block:: cpp\n\n py::type T_py = py::type::of();\n\nYou can directly use ``py::type::of(ob)`` to get the type object from any python\nobject, just like ``type(ob)`` in Python.\n\n.. note::\n\n Other types, like ``py::type::of()``, do not work, see :ref:`type-conversions`.\n\n.. versionadded:: 2.6\n\nCustom type setup\n=================\n\nFor advanced use cases, such as enabling garbage collection support, you may\nwish to directly manipulate the ``PyHeapTypeObject`` corresponding to a\n``py::class_`` definition.\n\nYou can do that using ``py::custom_type_setup``:\n\n.. code-block:: cpp\n\n struct ContainerOwnsPythonObjects {\n std::vector list;\n\n void append(const py::object &obj) { list.emplace_back(obj); }\n py::object at(py::ssize_t index) const {\n if (index >= size() || index < 0) {\n throw py::index_error(\"Index out of range\");\n }\n return list.at(py::size_t(index));\n }\n py::ssize_t size() const { return py::ssize_t_cast(list.size()); }\n void clear() { list.clear(); }\n };\n\n py::class_ cls(\n m, \"ContainerOwnsPythonObjects\", py::custom_type_setup([](PyHeapTypeObject *heap_type) {\n auto *type = &heap_type->ht_type;\n type->tp_flags |= Py_TPFLAGS_HAVE_GC;\n type->tp_traverse = [](PyObject *self_base, visitproc visit, void *arg) {\n // https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_traverse\n #if PY_VERSION_HEX >= 0x03090000\n Py_VISIT(Py_TYPE(self_base));\n #endif\n if (py::detail::is_holder_constructed(self_base)) {\n auto &self = py::cast(py::handle(self_base));\n for (auto &item : self.list) {\n Py_VISIT(item.ptr());\n }\n }\n return 0;\n };\n type->tp_clear = [](PyObject *self_base) {\n if (py::detail::is_holder_constructed(self_base)) {\n auto &self = py::cast(py::handle(self_base));\n for (auto &item : self.list) {\n Py_CLEAR(item.ptr());\n }\n self.list.clear();\n }\n return 0;\n };\n }));\n cls.def(py::init<>());\n cls.def(\"append\", &ContainerOwnsPythonObjects::append);\n cls.def(\"at\", &ContainerOwnsPythonObjects::at);\n cls.def(\"size\", &ContainerOwnsPythonObjects::size);\n cls.def(\"clear\", &ContainerOwnsPythonObjects::clear);\n\n.. versionadded:: 2.8\n" }, { "path": "docs/advanced/deadlock.md", "content": "# Double locking, deadlocking, GIL\n\n[TOC]\n\n## Introduction\n\n### Overview\n\nIn concurrent programming with locks, *deadlocks* can arise when more than one\nmutex is locked at the same time, and careful attention has to be paid to lock\nordering to avoid this. Here we will look at a common situation that occurs in\nnative extensions for CPython written in C++.\n\n### Deadlocks\n\nA deadlock can occur when more than one thread attempts to lock more than one\nmutex, and two of the threads lock two of the mutexes in different orders. For\nexample, consider mutexes `mu1` and `mu2`, and threads T1 and T2, executing:\n\n| | T1 | T2 |\n|--- | ------------------- | -------------------|\n|1 | `mu1.lock()`{.good} | `mu2.lock()`{.good}|\n|2 | `mu2.lock()`{.bad} | `mu1.lock()`{.bad} |\n|3 | `/* work */` | `/* work */` |\n|4 | `mu2.unlock()` | `mu1.unlock()` |\n|5 | `mu1.unlock()` | `mu2.unlock()` |\n\nNow if T1 manages to lock `mu1` and T2 manages to lock `mu2` (as indicated in\ngreen), then both threads will block while trying to lock the respective other\nmutex (as indicated in red), but they are also unable to release the mutex that\nthey have locked (step 5).\n\n**The problem** is that it is possible for one thread to attempt to lock `mu1`\nand then `mu2`, and for another thread to attempt to lock `mu2` and then `mu1`.\nNote that it does not matter if either mutex is unlocked at any intermediate\npoint; what matters is only the order of any attempt to *lock* the mutexes. For\nexample, the following, more complex series of operations is just as prone to\ndeadlock:\n\n| | T1 | T2 |\n|--- | ------------------- | -------------------|\n|1 | `mu1.lock()`{.good} | `mu1.lock()`{.good}|\n|2 | waiting for T2 | `mu2.lock()`{.good}|\n|3 | waiting for T2 | `/* work */` |\n|3 | waiting for T2 | `mu1.unlock()` |\n|3 | `mu2.lock()`{.bad} | `/* work */` |\n|3 | `/* work */` | `mu1.lock()`{.bad} |\n|3 | `/* work */` | `/* work */` |\n|4 | `mu2.unlock()` | `mu1.unlock()` |\n|5 | `mu1.unlock()` | `mu2.unlock()` |\n\nWhen the mutexes involved in a locking sequence are known at compile-time, then\navoiding deadlocks is “merely” a matter of arranging the lock\noperations carefully so as to only occur in one single, fixed order. However, it\nis also possible for mutexes to only be determined at runtime. A typical example\nof this is a database where each row has its own mutex. An operation that\nmodifies two rows in a single transaction (e.g. “transferring an amount\nfrom one account to another”) must lock two row mutexes, but the locking\norder cannot be established at compile time. In this case, a dynamic\n“deadlock avoidance algorithm” is needed. (In C++, `std::lock`\nprovides such an algorithm. An algorithm might use a non-blocking `try_lock`\noperation on a mutex, which can either succeed or fail to lock the mutex, but\nreturns without blocking.)\n\nConceptually, one could also consider it a deadlock if _the same_ thread\nattempts to lock a mutex that it has already locked (e.g. when some locked\noperation accidentally recurses into itself): `mu.lock();`{.good}\n`mu.lock();`{.bad} However, this is a slightly separate issue: Typical mutexes\nare either of _recursive_ or _non-recursive_ kind. A recursive mutex allows\nrepeated locking and requires balanced unlocking. A non-recursive mutex can be\nimplemented more efficiently, and/but for efficiency reasons does not actually\nguarantee a deadlock on second lock. Instead, the API simply forbids such use,\nmaking it a precondition that the thread not already hold the mutex, with\nundefined behaviour on violation.\n\n### “Once” initialization\n\nA common programming problem is to have an operation happen precisely once, even\nif requested concurrently. While it is clear that we need to track in some\nshared state somewhere whether the operation has already happened, it is worth\nnoting that this state only ever transitions, once, from `false` to `true`. This\nis considerably simpler than a general shared state that can change values\narbitrarily. Next, we also need a mechanism for all but one thread to block\nuntil the initialization has completed, which we can provide with a mutex. The\nsimplest solution just always locks the mutex:\n\n```c++\n// The \"once\" mechanism:\nconstinit absl::Mutex mu(absl::kConstInit);\nconstinit bool init_done = false;\n\n// The operation of interest:\nvoid f();\n\nvoid InitOnceNaive() {\n absl::MutexLock lock(&mu);\n if (!init_done) {\n f();\n init_done = true;\n }\n}\n```\n\nThis works, but the efficiency-minded reader will observe that once the\noperation has completed, all future lock contention on the mutex is\nunnecessary. This leads to the (in)famous “double-locking”\nalgorithm, which was historically hard to write correctly. The idea is to check\nthe boolean *before* locking the mutex, and avoid locking if the operation has\nalready completed. However, accessing shared state concurrently when at least\none access is a write is prone to causing a data race and needs to be done\naccording to an appropriate concurrent programming model. In C++ we use atomic\nvariables:\n\n```c++\n// The \"once\" mechanism:\nconstinit absl::Mutex mu(absl::kConstInit);\nconstinit std::atomic init_done = false;\n\n// The operation of interest:\nvoid f();\n\nvoid InitOnceWithFastPath() {\n if (!init_done.load(std::memory_order_acquire)) {\n absl::MutexLock lock(&mu);\n if (!init_done.load(std::memory_order_relaxed)) {\n f();\n init_done.store(true, std::memory_order_release);\n }\n }\n}\n```\n\nChecking the flag now happens without holding the mutex lock, and if the\noperation has already completed, we return immediately. After locking the mutex,\nwe need to check the flag again, since multiple threads can reach this point.\n\n*Atomic details.* Since the atomic flag variable is accessed concurrently, we\nhave to think about the memory order of the accesses. There are two separate\ncases: The first, outer check outside the mutex lock, and the second, inner\ncheck under the lock. The outer check and the flag update form an\nacquire/release pair: *if* the load sees the value `true` (which must have been\nwritten by the store operation), then it also sees everything that happened\nbefore the store, namely the operation `f()`. By contrast, the inner check can\nuse relaxed memory ordering, since in that case the mutex operations provide the\nnecessary ordering: if the inner load sees the value `true`, it happened after\nthe `lock()`, which happened after the `unlock()`, which happened after the\nstore.\n\nThe C++ standard library, and Abseil, provide a ready-made solution of this\nalgorithm called `std::call_once`/`absl::call_once`. (The interface is the same,\nbut the Abseil implementation is possibly better.)\n\n```c++\n// The \"once\" mechanism:\nconstinit absl::once_flag init_flag;\n\n// The operation of interest:\nvoid f();\n\nvoid InitOnceWithCallOnce() {\n absl::call_once(once_flag, f);\n}\n```\n\nEven though conceptually this is performing the same algorithm, this\nimplementation has some considerable advantages: The `once_flag` type is a small\nand trivial, integer-like type and is trivially destructible. Not only does it\ntake up less space than a mutex, it also generates less code since it does not\nhave to run a destructor, which would need to be added to the program's global\ndestructor list.\n\nThe final clou comes with the C++ semantics of a `static` variable declared at\nblock scope: According to [[stmt.dcl]](https://eel.is/c++draft/stmt.dcl#3):\n\n> Dynamic initialization of a block variable with static storage duration or\n> thread storage duration is performed the first time control passes through its\n> declaration; such a variable is considered initialized upon the completion of\n> its initialization. [...] If control enters the declaration concurrently while\n> the variable is being initialized, the concurrent execution shall wait for\n> completion of the initialization.\n\nThis is saying that the initialization of a local, `static` variable precisely\nhas the “once” semantics that we have been discussing. We can\ntherefore write the above example as follows:\n\n```c++\n// The operation of interest:\nvoid f();\n\nvoid InitOnceWithStatic() {\n static int unused = (f(), 0);\n}\n```\n\nThis approach is by far the simplest and easiest, but the big difference is that\nthe mutex (or mutex-like object) in this implementation is no longer visible or\nin the user’s control. This is perfectly fine if the initializer is\nsimple, but if the initializer itself attempts to lock any other mutex\n(including by initializing another static variable!), then we have no control\nover the lock ordering!\n\nFinally, you may have noticed the `constinit`s around the earlier code. Both\n`constinit` and `constexpr` specifiers on a declaration mean that the variable\nis *constant-initialized*, which means that no initialization is performed at\nruntime (the initial value is already known at compile time). This in turn means\nthat a static variable guard mutex may not be needed, and static initialization\nnever blocks. The difference between the two is that a `constexpr`-specified\nvariable is also `const`, and a variable cannot be `constexpr` if it has a\nnon-trivial destructor. Such a destructor also means that the guard mutex is\nneeded after all, since the destructor must be registered to run at exit,\nconditionally on initialization having happened.\n\n## Python, CPython, GIL\n\nWith CPython, a Python program can call into native code. To this end, the\nnative code registers callback functions with the Python runtime via the CPython\nAPI. In order to ensure that the internal state of the Python runtime remains\nconsistent, there is a single, shared mutex called the “global interpreter\nlock”, or GIL for short. Upon entry of one of the user-provided callback\nfunctions, the GIL is locked (or “held”), so that no other mutations\nof the Python runtime state can occur until the native callback returns.\n\nMany native extensions do not interact with the Python runtime for at least some\npart of them, and so it is common for native extensions to _release_ the GIL, do\nsome work, and then reacquire the GIL before returning. Similarly, when code is\ngenerally not holding the GIL but needs to interact with the runtime briefly, it\nwill first reacquire the GIL. The GIL is reentrant, and constructions to acquire\nand subsequently release the GIL are common, and often don't worry about whether\nthe GIL is already held.\n\nIf the native code is written in C++ and contains local, `static` variables,\nthen we are now dealing with at least _two_ mutexes: the static variable guard\nmutex, and the GIL from CPython.\n\nA common problem in such code is an operation with “only once”\nsemantics that also ends up requiring the GIL to be held at some point. As per\nthe above description of “once”-style techniques, one might find a\nstatic variable:\n\n```c++\n// CPython callback, assumes that the GIL is held on entry.\nPyObject* InvokeWidget(PyObject* self) {\n static PyObject* impl = CreateWidget();\n return PyObject_CallOneArg(impl, self);\n}\n```\n\nThis seems reasonable, but bear in mind that there are two mutexes (the \"guard\nmutex\" and \"the GIL\"), and we must think about the lock order. Otherwise, if the\ncallback is called from multiple threads, a deadlock may ensue.\n\nLet us consider what we can see here: On entry, the GIL is already locked, and\nwe are locking the guard mutex. This is one lock order. Inside the initializer\n`CreateWidget`, with both mutexes already locked, the function can freely access\nthe Python runtime.\n\nHowever, it is entirely possible that `CreateWidget` will want to release the\nGIL at one point and reacquire it later:\n\n```c++\n// Assumes that the GIL is held on entry.\n// Ensures that the GIL is held on exit.\nPyObject* CreateWidget() {\n // ...\n Py_BEGIN_ALLOW_THREADS // releases GIL\n // expensive work, not accessing the Python runtime\n Py_END_ALLOW_THREADS // acquires GIL, #!\n // ...\n return result;\n}\n```\n\nNow we have a second lock order: the guard mutex is locked, and then the GIL is\nlocked (at `#!`). To see how this deadlocks, consider threads T1 and T2 both\nhaving the runtime attempt to call `InvokeWidget`. T1 locks the GIL and\nproceeds, locking the guard mutex and calling `CreateWidget`; T2 is blocked\nwaiting for the GIL. Then T1 releases the GIL to do “expensive\nwork”, and T2 awakes and locks the GIL. Now T2 is blocked trying to\nacquire the guard mutex, but T1 is blocked reacquiring the GIL (at `#!`).\n\nIn other words: if we want to support “once-called” functions that\ncan arbitrarily release and reacquire the GIL, as is very common, then the only\nlock order that we can ensure is: guard mutex first, GIL second.\n\nTo implement this, we must rewrite our code. Naively, we could always release\nthe GIL before a `static` variable with blocking initializer:\n\n```c++\n// CPython callback, assumes that the GIL is held on entry.\nPyObject* InvokeWidget(PyObject* self) {\n Py_BEGIN_ALLOW_THREADS // releases GIL\n static PyObject* impl = CreateWidget();\n Py_END_ALLOW_THREADS // acquires GIL\n\n return PyObject_CallOneArg(impl, self);\n}\n```\n\nBut similar to the `InitOnceNaive` example above, this code cycles the GIL\n(possibly descheduling the thread) even when the static variable has already\nbeen initialized. If we want to avoid this, we need to abandon the use of a\nstatic variable, since we do not control the guard mutex well enough. Instead,\nwe use an operation whose mutex locking is under our control, such as\n`call_once`. For example:\n\n```c++\n// CPython callback, assumes that the GIL is held on entry.\nPyObject* InvokeWidget(PyObject* self) {\n static constinit PyObject* impl = nullptr;\n static constinit std::atomic init_done = false;\n static constinit absl::once_flag init_flag;\n\n if (!init_done.load(std::memory_order_acquire)) {\n Py_BEGIN_ALLOW_THREADS // releases GIL\n absl::call_once(init_flag, [&]() {\n PyGILState_STATE s = PyGILState_Ensure(); // acquires GIL\n impl = CreateWidget();\n PyGILState_Release(s); // releases GIL\n init_done.store(true, std::memory_order_release);\n });\n Py_END_ALLOW_THREADS // acquires GIL\n }\n\n return PyObject_CallOneArg(impl, self);\n}\n```\n\nThe lock order is now always guard mutex first, GIL second. Unfortunately we\nhave to duplicate the “double-checked done flag”, effectively\nleading to triple checking, because the flag state inside the `absl::once_flag`\nis not accessible to the user. In other words, we cannot ask `init_flag` whether\nit has been used yet.\n\nHowever, we can perform one last, minor optimisation: since we assume that the\nGIL is held on entry, and again when the initializing operation returns, the GIL\nactually serializes access to our done flag variable, which therefore does not\nneed to be atomic. (The difference to the previous, atomic code may be small,\ndepending on the architecture. For example, on x86-64, acquire/release on a bool\nis nearly free ([demo](https://godbolt.org/z/P9vYWf4fE)).)\n\n```c++\n// CPython callback, assumes that the GIL is held on entry, and indeed anywhere\n// directly in this function (i.e. the GIL can be released inside CreateWidget,\n// but must be reaqcuired when that call returns).\nPyObject* InvokeWidget(PyObject* self) {\n static constinit PyObject* impl = nullptr;\n static constinit bool init_done = false; // guarded by GIL\n static constinit absl::once_flag init_flag;\n\n if (!init_done) {\n Py_BEGIN_ALLOW_THREADS // releases GIL\n // (multiple threads may enter here)\n absl::call_once(init_flag, [&]() {\n // (only one thread enters here)\n PyGILState_STATE s = PyGILState_Ensure(); // acquires GIL\n impl = CreateWidget();\n init_done = true; // (GIL is held)\n PyGILState_Release(s); // releases GIL\n });\n\n Py_END_ALLOW_THREADS // acquires GIL\n }\n\n return PyObject_CallOneArg(impl, self);\n}\n```\n\n## Debugging tips\n\n* Build with symbols.\n* Ctrl-C sends `SIGINT`, Ctrl-\\\\\n sends `SIGQUIT`. Both have their uses.\n* Useful `gdb` commands:\n * `py-bt` prints a Python backtrace if you are in a Python frame.\n * `thread apply all bt 10` prints the top-10 frames for each thread. A\n full backtrace can be prohibitively expensive, and the top few frames\n are often good enough.\n * `p PyGILState_Check()` shows whether a thread is holding the GIL. For\n all threads, run `thread apply all p PyGILState_Check()` to find out\n which thread is holding the GIL.\n * The `static` variable guard mutex is accessed with functions like\n `cxa_guard_acquire` (though this depends on ABI details and can vary).\n The guard mutex itself contains information about which thread is\n currently holding it.\n\n## Links\n\n* Article on\n [double-checked locking](https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/)\n* [The Deadlock Empire](https://deadlockempire.github.io/), hands-on exercises\n to construct deadlocks\n" }, { "path": "docs/advanced/deprecated.rst", "content": ".. _deprecated:\n\nDeprecated\n##########\n\nSupport for Python 3.8 is deprecated and will be removed in 3.1.\n\nSupport for C++11 is deprecated and will be removed in a future version. Please\nuse at least C++14.\n\nSupport for FindPythonLibs (not available in CMake 3.26+ mode) is deprecated\nand will be removed in a future version. The default mode is also going to\nchange to ``\"new\"`` from ``\"compat\"`` in the future.\n\nThe following features were deprecated before pybind11 3.0, and may be removed\nin minor releases of pybind11 3.x.\n\n.. list-table:: Deprecated Features\n :header-rows: 1\n :widths: 30 15 10\n\n * - Feature\n - Deprecated Version\n - Year\n * - ``py::metaclass()``\n - 2.1\n - 2017\n * - ``PYBIND11_PLUGIN``\n - 2.2\n - 2017\n * - ``py::set_error()`` replacing ``operator()``\n - 2.12\n - 2024\n * - ``get_type_overload``\n - 2.6\n - 2020\n * - ``call()``\n - 2.0\n - 2016\n * - ``.str()``\n - ?\n -\n * - ``.get_type()``\n - 2.6\n -\n * - ``==`` and ``!=``\n - 2.2\n - 2017\n * - ``.check()``\n - ?\n -\n * - ``object(handle, bool)``\n - ?\n -\n * - ``error_already_set.clear()``\n - 2.2\n - 2017\n * - ``obj.attr(…)`` as ``bool``\n - ?\n -\n * - ``.contains``\n - ? (maybe 2.4)\n -\n * - ``py::capsule`` two-argument with destructor\n - ?\n -\n\n\n\n.. _deprecated_enum:\n\n``py::enum_``\n=============\n\nThis is the original documentation for ``py::enum_``, which is deprecated\nbecause it is not `PEP 435 compatible `_\n(see also `#2332 `_).\nPlease prefer ``py::native_enum`` (added with pybind11v3) when writing\nnew bindings. See :ref:`native_enum` for more information.\n\nLet's suppose that we have an example class that contains internal types\nlike enumerations, e.g.:\n\n.. code-block:: cpp\n\n struct Pet {\n enum Kind {\n Dog = 0,\n Cat\n };\n\n struct Attributes {\n float age = 0;\n };\n\n Pet(const std::string &name, Kind type) : name(name), type(type) { }\n\n std::string name;\n Kind type;\n Attributes attr;\n };\n\nThe binding code for this example looks as follows:\n\n.. code-block:: cpp\n\n py::class_ pet(m, \"Pet\");\n\n pet.def(py::init())\n .def_readwrite(\"name\", &Pet::name)\n .def_readwrite(\"type\", &Pet::type)\n .def_readwrite(\"attr\", &Pet::attr);\n\n py::enum_(pet, \"Kind\")\n .value(\"Dog\", Pet::Kind::Dog)\n .value(\"Cat\", Pet::Kind::Cat)\n .export_values();\n\n py::class_(pet, \"Attributes\")\n .def(py::init<>())\n .def_readwrite(\"age\", &Pet::Attributes::age);\n\n\nTo ensure that the nested types ``Kind`` and ``Attributes`` are created within the scope of ``Pet``, the\n``pet`` ``py::class_`` instance must be supplied to the :class:`enum_` and ``py::class_``\nconstructor. The :func:`enum_::export_values` function exports the enum entries\ninto the parent scope, which should be skipped for newer C++11-style strongly\ntyped enums.\n\n.. code-block:: pycon\n\n >>> p = Pet(\"Lucy\", Pet.Cat)\n >>> p.type\n Kind.Cat\n >>> int(p.type)\n 1L\n\nThe entries defined by the enumeration type are exposed in the ``__members__`` property:\n\n.. code-block:: pycon\n\n >>> Pet.Kind.__members__\n {'Dog': Kind.Dog, 'Cat': Kind.Cat}\n\nThe ``name`` property returns the name of the enum value as a unicode string.\n\n.. note::\n\n It is also possible to use ``str(enum)``, however these accomplish different\n goals. The following shows how these two approaches differ.\n\n .. code-block:: pycon\n\n >>> p = Pet(\"Lucy\", Pet.Cat)\n >>> pet_type = p.type\n >>> pet_type\n Pet.Cat\n >>> str(pet_type)\n 'Pet.Cat'\n >>> pet_type.name\n 'Cat'\n\n.. note::\n\n When the special tag ``py::arithmetic()`` is specified to the ``enum_``\n constructor, pybind11 creates an enumeration that also supports rudimentary\n arithmetic and bit-level operations like comparisons, and, or, xor, negation,\n etc.\n\n .. code-block:: cpp\n\n py::enum_(pet, \"Kind\", py::arithmetic())\n ...\n\n By default, these are omitted to conserve space.\n\n.. warning::\n\n Contrary to Python customs, enum values from the wrappers should not be compared using ``is``, but with ``==`` (see `#1177 `_ for background).\n" }, { "path": "docs/advanced/embedding.rst", "content": ".. _embedding:\n\nEmbedding the interpreter\n#########################\n\nWhile pybind11 is mainly focused on extending Python using C++, it's also\npossible to do the reverse: embed the Python interpreter into a C++ program.\nAll of the other documentation pages still apply here, so refer to them for\ngeneral pybind11 usage. This section will cover a few extra things required\nfor embedding.\n\nGetting started\n===============\n\nA basic executable with an embedded interpreter can be created with just a few\nlines of CMake and the ``pybind11::embed`` target, as shown below. For more\ninformation, see :doc:`/compiling`.\n\n.. code-block:: cmake\n\n cmake_minimum_required(VERSION 3.15...4.2)\n project(example)\n\n find_package(pybind11 REQUIRED) # or `add_subdirectory(pybind11)`\n\n add_executable(example main.cpp)\n target_link_libraries(example PRIVATE pybind11::embed)\n\nThe essential structure of the ``main.cpp`` file looks like this:\n\n.. code-block:: cpp\n\n #include // everything needed for embedding\n namespace py = pybind11;\n\n int main() {\n py::scoped_interpreter guard{}; // start the interpreter and keep it alive\n\n py::print(\"Hello, World!\"); // use the Python API\n }\n\nThe interpreter must be initialized before using any Python API, which includes\nall the functions and classes in pybind11. The RAII guard class ``scoped_interpreter``\ntakes care of the interpreter lifetime. After the guard is destroyed, the interpreter\nshuts down and clears its memory. No Python functions can be called after this.\n\nExecuting Python code\n=====================\n\nThere are a few different ways to run Python code. One option is to use ``eval``,\n``exec`` or ``eval_file``, as explained in :ref:`eval`. Here is a quick example in\nthe context of an executable with an embedded interpreter:\n\n.. code-block:: cpp\n\n #include \n namespace py = pybind11;\n\n int main() {\n py::scoped_interpreter guard{};\n\n py::exec(R\"(\n kwargs = dict(name=\"World\", number=42)\n message = \"Hello, {name}! The answer is {number}\".format(**kwargs)\n print(message)\n )\");\n }\n\nAlternatively, similar results can be achieved using pybind11's API (see\n:doc:`/advanced/pycpp/index` for more details).\n\n.. code-block:: cpp\n\n #include \n namespace py = pybind11;\n using namespace py::literals;\n\n int main() {\n py::scoped_interpreter guard{};\n\n auto kwargs = py::dict(\"name\"_a=\"World\", \"number\"_a=42);\n auto message = \"Hello, {name}! The answer is {number}\"_s.format(**kwargs);\n py::print(message);\n }\n\nThe two approaches can also be combined:\n\n.. code-block:: cpp\n\n #include \n #include \n\n namespace py = pybind11;\n using namespace py::literals;\n\n int main() {\n py::scoped_interpreter guard{};\n\n auto locals = py::dict(\"name\"_a=\"World\", \"number\"_a=42);\n py::exec(R\"(\n message = \"Hello, {name}! The answer is {number}\".format(**locals())\n )\", py::globals(), locals);\n\n auto message = locals[\"message\"].cast();\n std::cout << message;\n }\n\nImporting modules\n=================\n\nPython modules can be imported using ``module_::import()``:\n\n.. code-block:: cpp\n\n py::module_ sys = py::module_::import(\"sys\");\n py::print(sys.attr(\"path\"));\n\nFor convenience, the current working directory is included in ``sys.path`` when\nembedding the interpreter. This makes it easy to import local Python files:\n\n.. code-block:: python\n\n \"\"\"calc.py located in the working directory\"\"\"\n\n\n def add(i, j):\n return i + j\n\n\n.. code-block:: cpp\n\n py::module_ calc = py::module_::import(\"calc\");\n py::object result = calc.attr(\"add\")(1, 2);\n int n = result.cast();\n assert(n == 3);\n\nModules can be reloaded using ``module_::reload()`` if the source is modified e.g.\nby an external process. This can be useful in scenarios where the application\nimports a user defined data processing script which needs to be updated after\nchanges by the user. Note that this function does not reload modules recursively.\n\n.. _embedding_modules:\n\nAdding embedded modules\n=======================\n\nEmbedded binary modules can be added using the ``PYBIND11_EMBEDDED_MODULE`` macro.\nNote that the definition must be placed at global scope. They can be imported\nlike any other module.\n\n.. code-block:: cpp\n\n #include \n namespace py = pybind11;\n\n PYBIND11_EMBEDDED_MODULE(fast_calc, m) {\n // `m` is a `py::module_` which is used to bind functions and classes\n m.def(\"add\", [](int i, int j) {\n return i + j;\n });\n }\n\n int main() {\n py::scoped_interpreter guard{};\n\n auto fast_calc = py::module_::import(\"fast_calc\");\n auto result = fast_calc.attr(\"add\")(1, 2).cast();\n assert(result == 3);\n }\n\nUnlike extension modules where only a single binary module can be created, on\nthe embedded side an unlimited number of modules can be added using multiple\n``PYBIND11_EMBEDDED_MODULE`` definitions (as long as they have unique names).\n\nThese modules are added to Python's list of builtins, so they can also be\nimported in pure Python files loaded by the interpreter. Everything interacts\nnaturally:\n\n.. code-block:: python\n\n \"\"\"py_module.py located in the working directory\"\"\"\n import cpp_module\n\n a = cpp_module.a\n b = a + 1\n\n\n.. code-block:: cpp\n\n #include \n namespace py = pybind11;\n\n PYBIND11_EMBEDDED_MODULE(cpp_module, m) {\n m.attr(\"a\") = 1;\n }\n\n int main() {\n py::scoped_interpreter guard{};\n\n auto py_module = py::module_::import(\"py_module\");\n\n auto locals = py::dict(\"fmt\"_a=\"{} + {} = {}\", **py_module.attr(\"__dict__\"));\n assert(locals[\"a\"].cast() == 1);\n assert(locals[\"b\"].cast() == 2);\n\n py::exec(R\"(\n c = a + b\n message = fmt.format(a, b, c)\n )\", py::globals(), locals);\n\n assert(locals[\"c\"].cast() == 3);\n assert(locals[\"message\"].cast() == \"1 + 2 = 3\");\n }\n\n``PYBIND11_EMBEDDED_MODULE`` also accepts\n:func:`py::mod_gil_not_used()`,\n:func:`py::multiple_interpreters::per_interpreter_gil()`, and\n:func:`py::multiple_interpreters::shared_gil()` tags just like ``PYBIND11_MODULE``.\nSee :ref:`misc_subinterp` and :ref:`misc_free_threading` for more information.\n\nInterpreter lifetime\n====================\n\nThe Python interpreter shuts down when ``scoped_interpreter`` is destroyed. After\nthis, creating a new instance will restart the interpreter. Alternatively, the\n``initialize_interpreter`` / ``finalize_interpreter`` pair of functions can be used\nto directly set the state at any time.\n\nModules created with pybind11 can be safely re-initialized after the interpreter\nhas been restarted. However, this may not apply to third-party extension modules.\nThe issue is that Python itself cannot completely unload extension modules and\nthere are several caveats with regard to interpreter restarting. In short, not\nall memory may be freed, either due to Python reference cycles or user-created\nglobal data. All the details can be found in the CPython documentation.\n\n.. warning::\n\n Creating two concurrent ``scoped_interpreter`` guards is a fatal error. So is\n calling ``initialize_interpreter`` for a second time after the interpreter\n has already been initialized. Use :class:`scoped_subinterpreter` to create\n a sub-interpreter. See :ref:`subinterp` for important details on sub-interpreters.\n\n Do not use the raw CPython API functions ``Py_Initialize`` and\n ``Py_Finalize`` as these do not properly handle the lifetime of\n pybind11's internal data.\n\n\n.. _subinterp:\n\nEmbedding Sub-interpreters\n==========================\n\nA sub-interpreter is a separate interpreter instance which provides a\nseparate, isolated interpreter environment within the same process as the main\ninterpreter. Sub-interpreters are created and managed with a separate API from\nthe main interpreter. Beginning in Python 3.12, sub-interpreters each have\ntheir own Global Interpreter Lock (GIL), which means that running a\nsub-interpreter in a separate thread from the main interpreter can achieve true\nconcurrency.\n\npybind11's sub-interpreter API can be found in ``pybind11/subinterpreter.h``.\n\npybind11 :class:`subinterpreter` instances can be safely moved and shared between\nthreads as needed. However, managing multiple threads and the lifetimes of multiple\ninterpreters and their GILs can be challenging.\nProceed with caution (and lots of testing)!\n\nThe main interpreter must be initialized before creating a sub-interpreter, and\nthe main interpreter must outlive all sub-interpreters. Sub-interpreters are\nmanaged through a different API than the main interpreter.\n\nThe :class:`subinterpreter` class manages the lifetime of sub-interpreters.\nInstances are movable, but not copyable. Default constructing this class does\n*not* create a sub-interpreter (it creates an empty holder). To create a\nsub-interpreter, call :func:`subinterpreter::create()`.\n\n.. warning::\n\n Sub-interpreter creation acquires (and subsequently releases) the main\n interpreter GIL. If another thread holds the main GIL, the function will\n block until the main GIL can be acquired.\n\n Sub-interpreter destruction temporarily activates the sub-interpreter. The\n sub-interpreter must not be active (on any threads) at the time the\n :class:`subinterpreter` destructor is called.\n\n Both actions will re-acquire any interpreter's GIL that was held prior to\n the call before returning (or return to no active interpreter if none was\n active at the time of the call).\n\nEach sub-interpreter will import a separate copy of each ``PYBIND11_EMBEDDED_MODULE``\nwhen those modules specify a ``multiple_interpreters`` tag. If a module does not\nspecify a ``multiple_interpreters`` tag, then Python will report an ``ImportError``\nif it is imported in a sub-interpreter.\n\npybind11 also has a :class:`scoped_subinterpreter` class, which creates and\nactivates a sub-interpreter when it is constructed, and deactivates and deletes\nit when it goes out of scope.\n\nActivating a Sub-interpreter\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nOnce a sub-interpreter is created, you can \"activate\" it on a thread (and\nacquire its GIL) by creating a :class:`subinterpreter_scoped_activate`\ninstance and passing it the sub-interpreter to be activated. The function\nwill acquire the sub-interpreter's GIL and make the sub-interpreter the\ncurrent active interpreter on the current thread for the lifetime of the\ninstance. When the :class:`subinterpreter_scoped_activate` instance goes out\nof scope, the sub-interpreter GIL is released and the prior interpreter that\nwas active on the thread (if any) is reactivated and it's GIL is re-acquired.\n\nWhen using ``subinterpreter_scoped_activate``:\n\n1. If the thread holds any interpreter's GIL:\n - That GIL is released\n2. The new sub-interpreter's GIL is acquired\n3. The new sub-interpreter is made active.\n4. When the scope ends:\n - The sub-interpreter's GIL is released\n - If there was a previous interpreter:\n - The old interpreter's GIL is re-acquired\n - The old interpreter is made active\n - Otherwise, no interpreter is currently active and no GIL is held.\n\nExample:\n\n.. code-block:: cpp\n\n py::initialize_interpreter();\n // Main GIL is held\n {\n py::subinterpreter sub = py::subinterpreter::create();\n // Main interpreter is still active, main GIL re-acquired\n {\n py::subinterpreter_scoped_activate guard(sub);\n // Sub-interpreter active, thread holds sub's GIL\n {\n py::subinterpreter_scoped_activate main_guard(py);\n // Sub's GIL was automatically released\n // Main interpreter active, thread holds main's GIL\n }\n // Back to sub-interpreter, thread holds sub's GIL again\n }\n // Main interpreter is active, main's GIL is held\n }\n\n\nGIL API for sub-interpreters\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n:class:`gil_scoped_release` and :class:`gil_scoped_acquire` can be used to\nmanage the GIL of a sub-interpreter just as they do for the main interpreter.\nThey both manage the GIL of the currently active interpreter, without the\nprogrammer having to do anything special or different. There is one important\ncaveat:\n\n.. note::\n\n When no interpreter is active through a\n :class:`subinterpreter_scoped_activate` instance (such as on a new thread),\n :class:`gil_scoped_acquire` will acquire the **main** GIL and\n activate the **main** interpreter.\n\n\nFull Sub-interpreter example\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nHere is an example showing how to create and activate sub-interpreters:\n\n.. code-block:: cpp\n\n #include \n #include \n #include \n\n namespace py = pybind11;\n\n PYBIND11_EMBEDDED_MODULE(printer, m, py::multiple_interpreters::per_interpreter_gil()) {\n m.def(\"which\", [](const std::string& when) {\n std::cout << when << \"; Current Interpreter is \"\n << py::subinterpreter::current().id()\n << std::endl;\n });\n }\n\n int main() {\n py::scoped_interpreter main_interp;\n\n py::module_::import(\"printer\").attr(\"which\")(\"First init\");\n\n {\n py::subinterpreter sub = py::subinterpreter::create();\n\n py::module_::import(\"printer\").attr(\"which\")(\"Created sub\");\n\n {\n py::subinterpreter_scoped_activate guard(sub);\n try {\n py::module_::import(\"printer\").attr(\"which\")(\"Activated sub\");\n }\n catch (py::error_already_set &e) {\n std::cerr << \"EXCEPTION \" << e.what() << std::endl;\n return 1;\n }\n }\n\n py::module_::import(\"printer\").attr(\"which\")(\"Deactivated sub\");\n\n {\n py::gil_scoped_release nogil;\n {\n py::subinterpreter_scoped_activate guard(sub);\n try {\n {\n py::subinterpreter_scoped_activate main_guard(py::subinterpreter::main());\n try {\n py::module_::import(\"printer\").attr(\"which\")(\"Main within sub\");\n }\n catch (py::error_already_set &e) {\n std::cerr << \"EXCEPTION \" << e.what() << std::endl;\n return 1;\n }\n }\n py::module_::import(\"printer\").attr(\"which\")(\"After Main, still within sub\");\n }\n catch (py::error_already_set &e) {\n std::cerr << \"EXCEPTION \" << e.what() << std::endl;\n return 1;\n }\n }\n }\n }\n\n py::module_::import(\"printer\").attr(\"which\")(\"At end\");\n\n return 0;\n }\n\nExpected output:\n\n.. code-block:: text\n\n First init; Current Interpreter is 0\n Created sub; Current Interpreter is 0\n Activated sub; Current Interpreter is 1\n Deactivated sub; Current Interpreter is 0\n Main within sub; Current Interpreter is 0\n After Main, still within sub; Current Interpreter is 1\n At end; Current Interpreter is 0\n\n.. warning::\n\n In Python 3.12 sub-interpreters must be destroyed in the same OS thread\n that created them. Failure to follow this rule may result in deadlocks\n or crashes when destroying the sub-interpreter on the wrong thread.\n\n This constraint is not present in Python 3.13+.\n\n\nBest Practices for sub-interpreter safety\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n- Never share Python objects across different interpreters.\n\n- :class:`error_already_set` objects contain a reference to the Python exception type,\n and :func:`error_already_set::what()` acquires the GIL. So Python exceptions must\n **never** be allowed to propagate past the enclosing\n :class:`subinterpreter_scoped_activate` instance!\n (So your try/catch should be *just inside* the scope covered by the\n :class:`subinterpreter_scoped_activate`.)\n\n- Avoid global/static state whenever possible. Instead, keep state within each interpreter,\n such as within the interpreter state dict, which can be accessed via\n ``subinterpreter::current().state_dict()``, or within instance members and tied to\n Python objects.\n\n- Avoid trying to \"cache\" Python objects in C++ variables across function calls (this is an easy\n way to accidentally introduce sub-interpreter bugs). In the code example above, note that we\n did not save the result of :func:`module_::import`, in order to avoid accidentally using the\n resulting Python object when the wrong interpreter was active.\n\n- Avoid moving or disarming RAII objects managing GIL and sub-interpreter lifetimes. Doing so can\n lead to confusion about lifetimes. (For example, accidentally extending a\n :class:`subinterpreter_scoped_activate` past the lifetime of it's :class:`subinterpreter`.)\n\n- While sub-interpreters each have their own GIL, there can now be multiple independent GILs in one\n program so you need to consider the possibility of deadlocks caused by multiple GILs and/or the\n interactions of the GIL(s) and your C++ code's own locking.\n\n- When using multiple threads to run independent sub-interpreters, the independent GILs allow\n concurrent calls from different interpreters into the same C++ code from different threads.\n So you must still consider the thread safety of your C++ code. Remember, in Python 3.12\n sub-interpreters must be destroyed on the same thread that they were created on.\n\n- When using sub-interpreters in free-threaded python builds, note that creating and destroying\n sub-interpreters may initiate a \"stop-the-world\". Be sure to detach long-running C++ threads\n from Python thread state (similar to releasing the GIL) to avoid deadlocks.\n\n- Familiarize yourself with :ref:`misc_concurrency`.\n" }, { "path": "docs/advanced/exceptions.rst", "content": "Exceptions\n##########\n\nBuilt-in C++ to Python exception translation\n============================================\n\nWhen Python calls C++ code through pybind11, pybind11 provides a C++ exception handler\nthat will trap C++ exceptions, translate them to the corresponding Python exception,\nand raise them so that Python code can handle them.\n\npybind11 defines translations for ``std::exception`` and its standard\nsubclasses, and several special exception classes that translate to specific\nPython exceptions. Note that these are not actually Python exceptions, so they\ncannot be examined using the Python C API. Instead, they are pure C++ objects\nthat pybind11 will translate the corresponding Python exception when they arrive\nat its exception handler.\n\n.. tabularcolumns:: |p{0.5\\textwidth}|p{0.45\\textwidth}|\n\n+--------------------------------------+--------------------------------------+\n| Exception thrown by C++ | Translated to Python exception type |\n+======================================+======================================+\n| :class:`std::exception` | ``RuntimeError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::bad_alloc` | ``MemoryError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::domain_error` | ``ValueError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::invalid_argument` | ``ValueError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::length_error` | ``ValueError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::out_of_range` | ``IndexError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::range_error` | ``ValueError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`std::overflow_error` | ``OverflowError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::stop_iteration` | ``StopIteration`` (used to implement |\n| | custom iterators) |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::index_error` | ``IndexError`` (used to indicate out |\n| | of bounds access in ``__getitem__``, |\n| | ``__setitem__``, etc.) |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::key_error` | ``KeyError`` (used to indicate out |\n| | of bounds access in ``__getitem__``, |\n| | ``__setitem__`` in dict-like |\n| | objects, etc.) |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::value_error` | ``ValueError`` (used to indicate |\n| | wrong value passed in |\n| | ``container.remove(...)``) |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::type_error` | ``TypeError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::buffer_error` | ``BufferError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::import_error` | ``ImportError`` |\n+--------------------------------------+--------------------------------------+\n| :class:`pybind11::attribute_error` | ``AttributeError`` |\n+--------------------------------------+--------------------------------------+\n| Any other exception | ``RuntimeError`` |\n+--------------------------------------+--------------------------------------+\n\nException translation is not bidirectional. That is, *catching* the C++\nexceptions defined above will not trap exceptions that originate from\nPython. For that, catch :class:`pybind11::error_already_set`. See :ref:`below\n` for further details.\n\nThere is also a special exception :class:`cast_error` that is thrown by\n:func:`handle::call` when the input arguments cannot be converted to Python\nobjects.\n\nRegistering custom translators\n==============================\n\nIf the default exception conversion policy described above is insufficient,\npybind11 also provides support for registering custom exception translators.\nSimilar to pybind11 classes, exception translators can be local to the module\nthey are defined in or global to the entire python session. To register a simple\nexception conversion that translates a C++ exception into a new Python exception\nusing the C++ exception's ``what()`` method, a helper function is available:\n\n.. code-block:: cpp\n\n py::register_exception(module, \"PyExp\");\n\nThis call creates a Python exception class with the name ``PyExp`` in the given\nmodule and automatically converts any encountered exceptions of type ``CppExp``\ninto Python exceptions of type ``PyExp``.\n\nA matching function is available for registering a local exception translator:\n\n.. code-block:: cpp\n\n py::register_local_exception(module, \"PyExp\");\n\n\nIt is possible to specify base class for the exception using the third\nparameter, a ``handle``:\n\n.. code-block:: cpp\n\n py::register_exception(module, \"PyExp\", PyExc_RuntimeError);\n py::register_local_exception(module, \"PyExp\", PyExc_RuntimeError);\n\nThen ``PyExp`` can be caught both as ``PyExp`` and ``RuntimeError``.\n\nThe class objects of the built-in Python exceptions are listed in the Python\ndocumentation on `Standard Exceptions `_.\nThe default base class is ``PyExc_Exception``.\n\nWhen more advanced exception translation is needed, the functions\n``py::register_exception_translator(translator)`` and\n``py::register_local_exception_translator(translator)`` can be used to register\nfunctions that can translate arbitrary exception types (and which may include\nadditional logic to do so). The functions takes a stateless callable (e.g. a\nfunction pointer or a lambda function without captured variables) with the call\nsignature ``void(std::exception_ptr)``.\n\nWhen a C++ exception is thrown, the registered exception translators are tried\nin reverse order of registration (i.e. the last registered translator gets the\nfirst shot at handling the exception). All local translators will be tried\nbefore a global translator is tried.\n\nInside the translator, ``std::rethrow_exception`` should be used within\na try block to re-throw the exception. One or more catch clauses to catch\nthe appropriate exceptions should then be used with each clause using\n``py::set_error()`` (see below).\n\nTo declare a custom Python exception type, declare a ``py::exception`` variable\nand use this in the associated exception translator (note: it is often useful\nto make this a static declaration when using it inside a lambda expression\nwithout requiring capturing).\n\nThe following example demonstrates this for a hypothetical exception classes\n``MyCustomException`` and ``OtherException``: the first is translated to a\ncustom python exception ``MyCustomError``, while the second is translated to a\nstandard python RuntimeError:\n\n.. code-block:: cpp\n\n PYBIND11_CONSTINIT static py::gil_safe_call_once_and_store exc_storage;\n exc_storage.call_once_and_store_result(\n [&]() { return py::exception(m, \"MyCustomError\"); });\n py::register_exception_translator([](std::exception_ptr p) {\n try {\n if (p) std::rethrow_exception(p);\n } catch (const MyCustomException &e) {\n py::set_error(exc_storage.get_stored(), e.what());\n } catch (const OtherException &e) {\n py::set_error(PyExc_RuntimeError, e.what());\n }\n });\n\nMultiple exceptions can be handled by a single translator, as shown in the\nexample above. If the exception is not caught by the current translator, the\npreviously registered one gets a chance.\n\nIf none of the registered exception translators is able to handle the\nexception, it is handled by the default converter as described in the previous\nsection.\n\n.. seealso::\n\n The file :file:`tests/test_exceptions.cpp` contains examples\n of various custom exception translators and custom exception types.\n\n.. note::\n\n Call ``py::set_error()`` for every exception caught in a custom exception\n translator. Failure to do so will cause Python to crash with ``SystemError:\n error return without exception set``.\n\n Exceptions that you do not plan to handle should simply not be caught, or\n may be explicitly (re-)thrown to delegate it to the other,\n previously-declared existing exception translators.\n\n Note that ``libc++`` and ``libstdc++`` `behave differently under macOS\n `_\n with ``-fvisibility=hidden``. Therefore exceptions that are used across ABI\n boundaries need to be explicitly exported, as exercised in\n ``tests/test_exceptions.h``. See also:\n \"Problems with C++ exceptions\" under `GCC Wiki `_.\n\n\nLocal vs Global Exception Translators\n=====================================\n\nWhen a global exception translator is registered, it will be applied across all\nmodules in the reverse order of registration. This can create behavior where the\norder of module import influences how exceptions are translated.\n\nIf module1 has the following translator:\n\n.. code-block:: cpp\n\n py::register_exception_translator([](std::exception_ptr p) {\n try {\n if (p) std::rethrow_exception(p);\n } catch (const std::invalid_argument &e) {\n py::set_error(PyExc_ArgumentError, \"module1 handled this\");\n }\n }\n\nand module2 has the following similar translator:\n\n.. code-block:: cpp\n\n py::register_exception_translator([](std::exception_ptr p) {\n try {\n if (p) std::rethrow_exception(p);\n } catch (const std::invalid_argument &e) {\n py::set_error(PyExc_ArgumentError, \"module2 handled this\");\n }\n }\n\nthen which translator handles the invalid_argument will be determined by the\norder that module1 and module2 are imported. Since exception translators are\napplied in the reverse order of registration, which ever module was imported\nlast will \"win\" and that translator will be applied.\n\nIf there are multiple pybind11 modules that share exception types (either\nstandard built-in or custom) loaded into a single python instance and\nconsistent error handling behavior is needed, then local translators should be\nused.\n\nChanging the previous example to use ``register_local_exception_translator``\nwould mean that when invalid_argument is thrown in the module2 code, the\nmodule2 translator will always handle it, while in module1, the module1\ntranslator will do the same.\n\n.. _handling_python_exceptions_cpp:\n\nHandling exceptions from Python in C++\n======================================\n\nWhen C++ calls Python functions, such as in a callback function or when\nmanipulating Python objects, and Python raises an ``Exception``, pybind11\nconverts the Python exception into a C++ exception of type\n:class:`pybind11::error_already_set` whose payload contains a C++ string textual\nsummary and the actual Python exception. ``error_already_set`` is used to\npropagate Python exception back to Python (or possibly, handle them in C++).\n\n.. tabularcolumns:: |p{0.5\\textwidth}|p{0.45\\textwidth}|\n\n+--------------------------------------+--------------------------------------+\n| Exception raised in Python | Thrown as C++ exception type |\n+======================================+======================================+\n| Any Python ``Exception`` | :class:`pybind11::error_already_set` |\n+--------------------------------------+--------------------------------------+\n\nFor example:\n\n.. code-block:: cpp\n\n try {\n // open(\"missing.txt\", \"r\")\n auto file = py::module_::import(\"io\").attr(\"open\")(\"missing.txt\", \"r\");\n auto text = file.attr(\"read\")();\n file.attr(\"close\")();\n } catch (py::error_already_set &e) {\n if (e.matches(PyExc_FileNotFoundError)) {\n py::print(\"missing.txt not found\");\n } else if (e.matches(PyExc_PermissionError)) {\n py::print(\"missing.txt found but not accessible\");\n } else {\n throw;\n }\n }\n\nNote that C++ to Python exception translation does not apply here, since that is\na method for translating C++ exceptions to Python, not vice versa. The error raised\nfrom Python is always ``error_already_set``.\n\nThis example illustrates this behavior:\n\n.. code-block:: cpp\n\n try {\n py::eval(\"raise ValueError('The Ring')\");\n } catch (py::value_error &boromir) {\n // Boromir never gets the ring\n assert(false);\n } catch (py::error_already_set &frodo) {\n // Frodo gets the ring\n py::print(\"I will take the ring\");\n }\n\n try {\n // py::value_error is a request for pybind11 to raise a Python exception\n throw py::value_error(\"The ball\");\n } catch (py::error_already_set &cat) {\n // cat won't catch the ball since\n // py::value_error is not a Python exception\n assert(false);\n } catch (py::value_error &dog) {\n // dog will catch the ball\n py::print(\"Run Spot run\");\n throw; // Throw it again (pybind11 will raise ValueError)\n }\n\nHandling errors from the Python C API\n=====================================\n\nWhere possible, use :ref:`pybind11 wrappers ` instead of calling\nthe Python C API directly. When calling the Python C API directly, in\naddition to manually managing reference counts, one must follow the pybind11\nerror protocol, which is outlined here.\n\nAfter calling the Python C API, if Python returns an error,\n``throw py::error_already_set();``, which allows pybind11 to deal with the\nexception and pass it back to the Python interpreter. This includes calls to\nthe error setting functions such as ``py::set_error()``.\n\n.. code-block:: cpp\n\n py::set_error(PyExc_TypeError, \"C API type error demo\");\n throw py::error_already_set();\n\n // But it would be easier to simply...\n throw py::type_error(\"pybind11 wrapper type error\");\n\nAlternately, to ignore the error, call `PyErr_Clear\n`_.\n\nAny Python error must be thrown or cleared, or Python/pybind11 will be left in\nan invalid state.\n\nHandling warnings from the Python C API\n=======================================\n\nWrappers for handling Python warnings are provided in ``pybind11/warnings.h``.\nThis header must be included explicitly; it is not transitively included via\n``pybind11/pybind11.h``.\n\nWarnings can be raised with the ``warn`` function:\n\n.. code-block:: cpp\n\n py::warnings::warn(\"This is a warning!\", PyExc_Warning);\n\n // Optionally, a `stack_level` can be specified.\n py::warnings::warn(\"Another one!\", PyExc_DeprecationWarning, 3);\n\nNew warning types can be registered at the module level using ``new_warning_type``:\n\n.. code-block:: cpp\n\n py::warnings::new_warning_type(m, \"CustomWarning\", PyExc_RuntimeWarning);\n\nChaining exceptions ('raise from')\n==================================\n\nPython has a mechanism for indicating that exceptions were caused by other\nexceptions:\n\n.. code-block:: py\n\n try:\n print(1 / 0)\n except Exception as exc:\n raise RuntimeError(\"could not divide by zero\") from exc\n\nTo do a similar thing in pybind11, you can use the ``py::raise_from`` function. It\nsets the current python error indicator, so to continue propagating the exception\nyou should ``throw py::error_already_set()``.\n\n.. code-block:: cpp\n\n try {\n py::eval(\"print(1 / 0\"));\n } catch (py::error_already_set &e) {\n py::raise_from(e, PyExc_RuntimeError, \"could not divide by zero\");\n throw py::error_already_set();\n }\n\n.. versionadded:: 2.8\n\n.. _unraisable_exceptions:\n\nHandling unraisable exceptions\n==============================\n\nIf a Python function invoked from a C++ destructor or any function marked\n``noexcept(true)`` (collectively, \"noexcept functions\") throws an exception, there\nis no way to propagate the exception, as such functions may not throw.\nShould they throw or fail to catch any exceptions in their call graph,\nthe C++ runtime calls ``std::terminate()`` to abort immediately.\n\nSimilarly, Python exceptions raised in a class's ``__del__`` method do not\npropagate, but ``sys.unraisablehook()`` `is triggered\n`_\nand an auditing event is logged.\n\nAny noexcept function should have a try-catch block that traps\nclass:`error_already_set` (or any other exception that can occur). Note that\npybind11 wrappers around Python exceptions such as\n:class:`pybind11::value_error` are *not* Python exceptions; they are C++\nexceptions that pybind11 catches and converts to Python exceptions. Noexcept\nfunctions cannot propagate these exceptions either. A useful approach is to\nconvert them to Python exceptions and then ``discard_as_unraisable`` as shown\nbelow.\n\n.. code-block:: cpp\n\n void nonthrowing_func() noexcept(true) {\n try {\n // ...\n } catch (py::error_already_set &eas) {\n // Discard the Python error using Python APIs, using the C++ magic\n // variable __func__. Python already knows the type and value and of the\n // exception object.\n eas.discard_as_unraisable(__func__);\n } catch (const std::exception &e) {\n // Log and discard C++ exceptions.\n third_party::log(e);\n }\n }\n\n.. versionadded:: 2.6\n" }, { "path": "docs/advanced/functions.rst", "content": "Functions\n#########\n\nBefore proceeding with this section, make sure that you are already familiar\nwith the basics of binding functions and classes, as explained in :doc:`/basics`\nand :doc:`/classes`. The following guide is applicable to both free and member\nfunctions, i.e. *methods* in Python.\n\n.. _return_value_policies:\n\nReturn value policies\n=====================\n\nPython and C++ use fundamentally different ways of managing the memory and\nlifetime of objects managed by them. This can lead to issues when creating\nbindings for functions that return a non-trivial type. Just by looking at the\ntype information, it is not clear whether Python should take charge of the\nreturned value and eventually free its resources, or if this is handled on the\nC++ side. For this reason, pybind11 provides several *return value policy*\nannotations that can be passed to the :func:`module_::def` and\n:func:`class_::def` functions. The default policy is\n:enum:`return_value_policy::automatic`.\n\nReturn value policies are tricky, and it's very important to get them right.\nJust to illustrate what can go wrong, consider the following simple example:\n\n.. code-block:: cpp\n\n /* Function declaration */\n Data *get_data() { return _data; /* (pointer to a static data structure) */ }\n ...\n\n /* Binding code */\n m.def(\"get_data\", &get_data); // <-- KABOOM, will cause crash when called from Python\n\nWhat's going on here? When ``get_data()`` is called from Python, the return\nvalue (a native C++ type) must be wrapped to turn it into a usable Python type.\nIn this case, the default return value policy (:enum:`return_value_policy::automatic`)\ncauses pybind11 to assume ownership of the static ``_data`` instance.\n\nWhen Python's garbage collector eventually deletes the Python\nwrapper, pybind11 will also attempt to delete the C++ instance (via ``operator\ndelete()``) due to the implied ownership. At this point, the entire application\nwill come crashing down, though errors could also be more subtle and involve\nsilent data corruption.\n\nIn the above example, the policy :enum:`return_value_policy::reference` should have\nbeen specified so that the global data instance is only *referenced* without any\nimplied transfer of ownership, i.e.:\n\n.. code-block:: cpp\n\n m.def(\"get_data\", &get_data, py::return_value_policy::reference);\n\nOn the other hand, this is not the right policy for many other situations,\nwhere ignoring ownership could lead to resource leaks.\nAs a developer using pybind11, it's important to be familiar with the different\nreturn value policies, including which situation calls for which one of them.\nThe following table provides an overview of available policies:\n\n.. tabularcolumns:: |p{0.5\\textwidth}|p{0.45\\textwidth}|\n\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| Return value policy | Description |\n+==================================================+============================================================================+\n| :enum:`return_value_policy::take_ownership` | Reference an existing object (i.e. do not create a new copy) and take |\n| | ownership. Python will call the destructor and delete operator when the |\n| | object's reference count reaches zero. Undefined behavior ensues when the |\n| | C++ side does the same, or when the data was not dynamically allocated. |\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| :enum:`return_value_policy::copy` | Create a new copy of the returned object, which will be owned by Python. |\n| | This policy is comparably safe because the lifetimes of the two instances |\n| | are decoupled. |\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| :enum:`return_value_policy::move` | Use ``std::move`` to move the return value contents into a new instance |\n| | that will be owned by Python. This policy is comparably safe because the |\n| | lifetimes of the two instances (move source and destination) are decoupled.|\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| :enum:`return_value_policy::reference` | Reference an existing object, but do not take ownership. The C++ side is |\n| | responsible for managing the object's lifetime and deallocating it when |\n| | it is no longer used. Warning: undefined behavior will ensue when the C++ |\n| | side deletes an object that is still referenced and used by Python. |\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| :enum:`return_value_policy::reference_internal` | If the return value is an lvalue reference or a pointer, the parent object |\n| | (the implicit ``this``, or ``self`` argument of the called method or |\n| | property) is kept alive for at least the lifespan of the return value. |\n| | **Otherwise this policy falls back to** :enum:`return_value_policy::move` |\n| | (see #5528). Internally, this policy works just like |\n| | :enum:`return_value_policy::reference` but additionally applies a |\n| | ``keep_alive<0, 1>`` *call policy* (described in the next section) that |\n| | prevents the parent object from being garbage collected as long as the |\n| | return value is referenced by Python. This is the default policy for |\n| | property getters created via ``def_property``, ``def_readwrite``, etc. |\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| :enum:`return_value_policy::automatic` | This policy falls back to the policy |\n| | :enum:`return_value_policy::take_ownership` when the return value is a |\n| | pointer. Otherwise, it uses :enum:`return_value_policy::move` or |\n| | :enum:`return_value_policy::copy` for rvalue and lvalue references, |\n| | respectively. See above for a description of what all of these different |\n| | policies do. This is the default policy for ``py::class_``-wrapped types. |\n+--------------------------------------------------+----------------------------------------------------------------------------+\n| :enum:`return_value_policy::automatic_reference` | As above, but use policy :enum:`return_value_policy::reference` when the |\n| | return value is a pointer. This is the default conversion policy for |\n| | function arguments when calling Python functions manually from C++ code |\n| | (i.e. via ``handle::operator()``) and the casters in ``pybind11/stl.h``. |\n| | You probably won't need to use this explicitly. |\n+--------------------------------------------------+----------------------------------------------------------------------------+\n\nReturn value policies can also be applied to properties:\n\n.. code-block:: cpp\n\n class_(m, \"MyClass\")\n .def_property(\"data\", &MyClass::getData, &MyClass::setData,\n py::return_value_policy::copy);\n\nTechnically, the code above applies the policy to both the getter and the\nsetter function, however, the setter doesn't really care about *return*\nvalue policies which makes this a convenient terse syntax. Alternatively,\ntargeted arguments can be passed through the :class:`cpp_function` constructor:\n\n.. code-block:: cpp\n\n class_(m, \"MyClass\")\n .def_property(\"data\",\n py::cpp_function(&MyClass::getData, py::return_value_policy::copy),\n py::cpp_function(&MyClass::setData)\n );\n\n.. warning::\n\n Code with invalid return value policies might access uninitialized memory or\n free data structures multiple times, which can lead to hard-to-debug\n non-determinism and segmentation faults, hence it is worth spending the\n time to understand all the different options in the table above.\n\n.. note::\n\n One important aspect of the above policies is that they only apply to\n instances which pybind11 has *not* seen before, in which case the policy\n clarifies essential questions about the return value's lifetime and\n ownership. When pybind11 knows the instance already (as identified by its\n type and address in memory), it will return the existing Python object\n wrapper rather than creating a new copy.\n\n.. note::\n\n The next section on :ref:`call_policies` discusses *call policies* that can be\n specified *in addition* to a return value policy from the list above. Call\n policies indicate reference relationships that can involve both return values\n and parameters of functions.\n\n.. note::\n\n As an alternative to elaborate call policies and lifetime management logic,\n consider using smart pointers (see the section on :ref:`smart_pointers` for\n details). Smart pointers can tell whether an object is still referenced from\n C++ or Python, which generally eliminates the kinds of inconsistencies that\n can lead to crashes or undefined behavior. For functions returning smart\n pointers, it is not necessary to specify a return value policy.\n\n.. _call_policies:\n\nAdditional call policies\n========================\n\nIn addition to the above return value policies, further *call policies* can be\nspecified to indicate dependencies between parameters or ensure a certain state\nfor the function call.\n\nKeep alive\n----------\n\nIn general, this policy is required when the C++ object is any kind of container\nand another object is being added to the container. ``keep_alive``\nindicates that the argument with index ``Patient`` should be kept alive at least\nuntil the argument with index ``Nurse`` is freed by the garbage collector. Argument\nindices start at one, while zero refers to the return value. For methods, index\n``1`` refers to the implicit ``this`` pointer, while regular arguments begin at\nindex ``2``. Arbitrarily many call policies can be specified. When a ``Nurse``\nwith value ``None`` is detected at runtime, the call policy does nothing.\n\nWhen the nurse is not a pybind11-registered type, the implementation internally\nrelies on the ability to create a *weak reference* to the nurse object. When\nthe nurse object is not a pybind11-registered type and does not support weak\nreferences, an exception will be thrown.\n\nIf you use an incorrect argument index, you will get a ``RuntimeError`` saying\n``Could not activate keep_alive!``. You should review the indices you're using.\n\nConsider the following example: here, the binding code for a list append\noperation ties the lifetime of the newly added element to the underlying\ncontainer:\n\n.. code-block:: cpp\n\n py::class_(m, \"List\")\n .def(\"append\", &List::append, py::keep_alive<1, 2>());\n\nFor consistency, the argument indexing is identical for constructors. Index\n``1`` still refers to the implicit ``this`` pointer, i.e. the object which is\nbeing constructed. Index ``0`` refers to the return type which is presumed to\nbe ``void`` when a constructor is viewed like a function. The following example\nties the lifetime of the constructor element to the constructed object:\n\n.. code-block:: cpp\n\n py::class_(m, \"Nurse\")\n .def(py::init(), py::keep_alive<1, 2>());\n\n.. note::\n\n ``keep_alive`` is analogous to the ``with_custodian_and_ward`` (if Nurse,\n Patient != 0) and ``with_custodian_and_ward_postcall`` (if Nurse/Patient ==\n 0) policies from Boost.Python.\n\nCall guard\n----------\n\nThe ``call_guard`` policy allows any scope guard type ``T`` to be placed\naround the function call. For example, this definition:\n\n.. code-block:: cpp\n\n m.def(\"foo\", foo, py::call_guard());\n\nis equivalent to the following pseudocode:\n\n.. code-block:: cpp\n\n m.def(\"foo\", [](args...) {\n T scope_guard;\n return foo(args...); // forwarded arguments\n });\n\nThe only requirement is that ``T`` is default-constructible, but otherwise any\nscope guard will work. This is very useful in combination with ``gil_scoped_release``.\nSee :ref:`gil`.\n\nMultiple guards can also be specified as ``py::call_guard``. The\nconstructor order is left to right and destruction happens in reverse.\n\n.. seealso::\n\n The file :file:`tests/test_call_policies.cpp` contains a complete example\n that demonstrates using `keep_alive` and `call_guard` in more detail.\n\n.. _python_objects_as_args:\n\nPython objects as arguments\n===========================\n\npybind11 exposes all major Python types using thin C++ wrapper classes. These\nwrapper classes can also be used as parameters of functions in bindings, which\nmakes it possible to directly work with native Python types on the C++ side.\nFor instance, the following statement iterates over a Python ``dict``:\n\n.. code-block:: cpp\n\n void print_dict(const py::dict& dict) {\n /* Easily interact with Python types */\n for (auto item : dict)\n std::cout << \"key=\" << std::string(py::str(item.first)) << \", \"\n << \"value=\" << std::string(py::str(item.second)) << std::endl;\n }\n\nIt can be exported:\n\n.. code-block:: cpp\n\n m.def(\"print_dict\", &print_dict);\n\nAnd used in Python as usual:\n\n.. code-block:: pycon\n\n >>> print_dict({\"foo\": 123, \"bar\": \"hello\"})\n key=foo, value=123\n key=bar, value=hello\n\nFor more information on using Python objects in C++, see :doc:`/advanced/pycpp/index`.\n\nAccepting \\*args and \\*\\*kwargs\n===============================\n\nPython provides a useful mechanism to define functions that accept arbitrary\nnumbers of arguments and keyword arguments:\n\n.. code-block:: python\n\n def generic(*args, **kwargs):\n ... # do something with args and kwargs\n\nSuch functions can also be created using pybind11:\n\n.. code-block:: cpp\n\n void generic(py::args args, const py::kwargs& kwargs) {\n /// .. do something with args\n if (kwargs)\n /// .. do something with kwargs\n }\n\n /// Binding code\n m.def(\"generic\", &generic);\n\nThe class ``py::args`` derives from ``py::tuple`` and ``py::kwargs`` derives\nfrom ``py::dict``.\n\nYou may also use just one or the other, and may combine these with other\narguments. Note, however, that ``py::kwargs`` must always be the last argument\nof the function, and ``py::args`` implies that any further arguments are\nkeyword-only (see :ref:`keyword_only_arguments`).\n\nPlease refer to the other examples for details on how to iterate over these,\nand on how to cast their entries into C++ objects. A demonstration is also\navailable in ``tests/test_kwargs_and_defaults.cpp``.\n\n.. note::\n\n When combining \\*args or \\*\\*kwargs with :ref:`keyword_args` you should\n *not* include ``py::arg`` tags for the ``py::args`` and ``py::kwargs``\n arguments.\n\nDefault arguments revisited\n===========================\n\nThe section on :ref:`default_args` previously discussed basic usage of default\narguments using pybind11. One noteworthy aspect of their implementation is that\ndefault arguments are converted to Python objects right at declaration time.\nConsider the following example:\n\n.. code-block:: cpp\n\n py::class_(\"MyClass\")\n .def(\"myFunction\", py::arg(\"arg\") = SomeType(123));\n\nIn this case, pybind11 must already be set up to deal with values of the type\n``SomeType`` (via a prior instantiation of ``py::class_``), or an\nexception will be thrown.\n\nAnother aspect worth highlighting is that the \"preview\" of the default argument\nin the function signature is generated using the object's ``__repr__`` method.\nIf not available, the signature may not be very helpful, e.g.:\n\n.. code-block:: pycon\n\n FUNCTIONS\n ...\n | myFunction(...)\n | Signature : (MyClass, arg : SomeType = ) -> NoneType\n ...\n\nThe first way of addressing this is by defining ``SomeType.__repr__``.\nAlternatively, it is possible to specify the human-readable preview of the\ndefault argument manually using the ``arg_v`` notation:\n\n.. code-block:: cpp\n\n py::class_(\"MyClass\")\n .def(\"myFunction\", py::arg_v(\"arg\", SomeType(123), \"SomeType(123)\"));\n\nSometimes it may be necessary to pass a null pointer value as a default\nargument. In this case, remember to cast it to the underlying type in question,\nlike so:\n\n.. code-block:: cpp\n\n py::class_(\"MyClass\")\n .def(\"myFunction\", py::arg(\"arg\") = static_cast(nullptr));\n\n.. _keyword_only_arguments:\n\nKeyword-only arguments\n======================\n\nPython implements keyword-only arguments by specifying an unnamed ``*``\nargument in a function definition:\n\n.. code-block:: python\n\n def f(a, *, b): # a can be positional or via keyword; b must be via keyword\n pass\n\n\n f(a=1, b=2) # good\n f(b=2, a=1) # good\n f(1, b=2) # good\n f(1, 2) # TypeError: f() takes 1 positional argument but 2 were given\n\nPybind11 provides a ``py::kw_only`` object that allows you to implement\nthe same behaviour by specifying the object between positional and keyword-only\nargument annotations when registering the function:\n\n.. code-block:: cpp\n\n m.def(\"f\", [](int a, int b) { /* ... */ },\n py::arg(\"a\"), py::kw_only(), py::arg(\"b\"));\n\n.. versionadded:: 2.6\n\nA ``py::args`` argument implies that any following arguments are keyword-only,\nas if ``py::kw_only()`` had been specified in the same relative location of the\nargument list as the ``py::args`` argument. The ``py::kw_only()`` may be\nincluded to be explicit about this, but is not required.\n\n.. versionchanged:: 2.9\n This can now be combined with ``py::args``. Before, ``py::args`` could only\n occur at the end of the argument list, or immediately before a ``py::kwargs``\n argument at the end.\n\n\nPositional-only arguments\n=========================\n\nPython 3.8 introduced a new positional-only argument syntax, using ``/`` in the\nfunction definition (note that this has been a convention for CPython\npositional arguments, such as in ``pow()``, since Python 2). You can\ndo the same thing in any version of Python using ``py::pos_only()``:\n\n.. code-block:: cpp\n\n m.def(\"f\", [](int a, int b) { /* ... */ },\n py::arg(\"a\"), py::pos_only(), py::arg(\"b\"));\n\nYou now cannot give argument ``a`` by keyword. This can be combined with\nkeyword-only arguments, as well.\n\n.. versionadded:: 2.6\n\n.. _nonconverting_arguments:\n\nNon-converting arguments\n========================\n\nCertain argument types may support conversion from one type to another. Some\nexamples of conversions are:\n\n* :ref:`implicit_conversions` declared using ``py::implicitly_convertible()``\n* Passing an argument that implements ``__float__`` or ``__index__`` to ``float`` or ``double``.\n* Passing an argument that implements ``__int__`` or ``__index__`` to ``int``.\n* Passing an argument that implements ``__complex__``, ``__float__``, or ``__index__`` to ``std::complex``.\n (Requires the optional ``pybind11/complex.h`` header).\n* Calling a function taking an Eigen matrix reference with a numpy array of the\n wrong type or of an incompatible data layout. (Requires the optional\n ``pybind11/eigen.h`` header).\n\nThis behaviour is sometimes undesirable: the binding code may prefer to raise\nan error rather than convert the argument. This behaviour can be obtained\nthrough ``py::arg`` by calling the ``.noconvert()`` method of the ``py::arg``\nobject, such as:\n\n.. code-block:: cpp\n\n m.def(\"supports_float\", [](double f) { return 0.5 * f; }, py::arg(\"f\"));\n m.def(\"only_float\", [](double f) { return 0.5 * f; }, py::arg(\"f\").noconvert());\n\n``supports_float`` will accept any argument that implements ``__float__`` or ``__index__``.\n``only_float`` will only accept a float or int argument. Anything else will fail with a ``TypeError``:\n\n.. note::\n\n The noconvert behaviour of float, double and complex has changed to match PEP 484.\n A float/double argument marked noconvert will accept float or int.\n A std::complex argument will accept complex, float or int.\n\n.. code-block:: pycon\n\n class MyFloat:\n def __init__(self, value: float) -> None:\n self._value = float(value)\n def __repr__(self) -> str:\n return f\"MyFloat({self._value})\"\n def __float__(self) -> float:\n return self._value\n\n >>> supports_float(MyFloat(4))\n 2.0\n >>> only_float(MyFloat(4))\n Traceback (most recent call last):\n File \"\", line 1, in \n TypeError: only_float(): incompatible function arguments. The following argument types are supported:\n 1. (f: float) -> float\n\n Invoked with: MyFloat(4)\n\nYou may, of course, combine this with the :var:`_a` shorthand notation (see\n:ref:`keyword_args`) and/or :ref:`default_args`. It is also permitted to omit\nthe argument name by using the ``py::arg()`` constructor without an argument\nname, i.e. by specifying ``py::arg().noconvert()``.\n\n.. note::\n\n When specifying ``py::arg`` options it is necessary to provide the same\n number of options as the bound function has arguments. Thus if you want to\n enable no-convert behaviour for just one of several arguments, you will\n need to specify a ``py::arg()`` annotation for each argument with the\n no-convert argument modified to ``py::arg().noconvert()``.\n\n.. _none_arguments:\n\nAllow/Prohibiting None arguments\n================================\n\nWhen a C++ type registered with :class:`py::class_` is passed as an argument to\na function taking the instance as pointer or shared holder (e.g. ``shared_ptr``\nor a custom, copyable holder as described in :ref:`smart_pointers`), pybind\nallows ``None`` to be passed from Python which results in calling the C++\nfunction with ``nullptr`` (or an empty holder) for the argument.\n\nTo explicitly enable or disable this behaviour, using the\n``.none`` method of the :class:`py::arg` object:\n\n.. code-block:: cpp\n\n py::class_(m, \"Dog\").def(py::init<>());\n py::class_(m, \"Cat\").def(py::init<>());\n m.def(\"bark\", [](Dog *dog) -> std::string {\n if (dog) return \"woof!\"; /* Called with a Dog instance */\n else return \"(no dog)\"; /* Called with None, dog == nullptr */\n }, py::arg(\"dog\").none(true));\n m.def(\"meow\", [](Cat *cat) -> std::string {\n // Can't be called with None argument\n return \"meow\";\n }, py::arg(\"cat\").none(false));\n\nWith the above, the Python call ``bark(None)`` will return the string ``\"(no\ndog)\"``, while attempting to call ``meow(None)`` will raise a ``TypeError``:\n\n.. code-block:: pycon\n\n >>> from animals import Dog, Cat, bark, meow\n >>> bark(Dog())\n 'woof!'\n >>> meow(Cat())\n 'meow'\n >>> bark(None)\n '(no dog)'\n >>> meow(None)\n Traceback (most recent call last):\n File \"\", line 1, in \n TypeError: meow(): incompatible function arguments. The following argument types are supported:\n 1. (cat: animals.Cat) -> str\n\n Invoked with: None\n\nThe default behaviour when the tag is unspecified is to allow ``None``.\n\n.. note::\n\n Even when ``.none(true)`` is specified for an argument, ``None`` will be converted to a\n ``nullptr`` *only* for custom and :ref:`opaque ` types. Pointers to built-in types\n (``double *``, ``int *``, ...) and STL types (``std::vector *``, ...; if ``pybind11/stl.h``\n is included) are copied when converted to C++ (see :doc:`/advanced/cast/overview`) and will\n not allow ``None`` as argument. To pass optional argument of these copied types consider\n using ``std::optional``\n\n.. _overload_resolution:\n\nOverload resolution order\n=========================\n\nWhen a function or method with multiple overloads is called from Python,\npybind11 determines which overload to call in two passes. The first pass\nattempts to call each overload without allowing argument conversion (as if\nevery argument had been specified as ``py::arg().noconvert()`` as described\nabove).\n\nIf no overload succeeds in the no-conversion first pass, a second pass is\nattempted in which argument conversion is allowed (except where prohibited via\nan explicit ``py::arg().noconvert()`` attribute in the function definition).\n\nIf the second pass also fails a ``TypeError`` is raised.\n\nWithin each pass, overloads are tried in the order they were registered with\npybind11. If the ``py::prepend()`` tag is added to the definition, a function\ncan be placed at the beginning of the overload sequence instead, allowing user\noverloads to proceed built in functions.\n\nWhat this means in practice is that pybind11 will prefer any overload that does\nnot require conversion of arguments to an overload that does, but otherwise\nprefers earlier-defined overloads to later-defined ones.\n\n.. note::\n\n pybind11 does *not* further prioritize based on the number/pattern of\n overloaded arguments. That is, pybind11 does not prioritize a function\n requiring one conversion over one requiring three, but only prioritizes\n overloads requiring no conversion at all to overloads that require\n conversion of at least one argument.\n\n.. versionadded:: 2.6\n\n The ``py::prepend()`` tag.\n\nBinding functions with template parameters\n==========================================\n\nYou can bind functions that have template parameters. Here's a function:\n\n.. code-block:: cpp\n\n template \n void set(T t);\n\nC++ templates cannot be instantiated at runtime, so you cannot bind the\nnon-instantiated function:\n\n.. code-block:: cpp\n\n // BROKEN (this will not compile)\n m.def(\"set\", &set);\n\nYou must bind each instantiated function template separately. You may bind\neach instantiation with the same name, which will be treated the same as\nan overloaded function:\n\n.. code-block:: cpp\n\n m.def(\"set\", &set);\n m.def(\"set\", &set);\n\nSometimes it's more clear to bind them with separate names, which is also\nan option:\n\n.. code-block:: cpp\n\n m.def(\"setInt\", &set);\n m.def(\"setString\", &set);\n" }, { "path": "docs/advanced/misc.rst", "content": "Miscellaneous\n#############\n\n.. _macro_notes:\n\nGeneral notes regarding convenience macros\n==========================================\n\npybind11 provides a few convenience macros such as\n:func:`PYBIND11_DECLARE_HOLDER_TYPE` and ``PYBIND11_OVERRIDE_*``. Since these\nare \"just\" macros that are evaluated in the preprocessor (which has no concept\nof types), they *will* get confused by commas in a template argument; for\nexample, consider:\n\n.. code-block:: cpp\n\n PYBIND11_OVERRIDE(MyReturnType, Class, func)\n\nThe limitation of the C preprocessor interprets this as five arguments (with new\narguments beginning after each comma) rather than three. To get around this,\nthere are two alternatives: you can use a type alias, or you can wrap the type\nusing the ``PYBIND11_TYPE`` macro:\n\n.. code-block:: cpp\n\n // Version 1: using a type alias\n using ReturnType = MyReturnType;\n using ClassType = Class;\n PYBIND11_OVERRIDE(ReturnType, ClassType, func);\n\n // Version 2: using the PYBIND11_TYPE macro:\n PYBIND11_OVERRIDE(PYBIND11_TYPE(MyReturnType),\n PYBIND11_TYPE(Class), func)\n\nThe ``PYBIND11_MAKE_OPAQUE`` macro does *not* require the above workarounds.\n\n.. _gil:\n\nGlobal Interpreter Lock (GIL)\n=============================\n\nThe Python C API dictates that the Global Interpreter Lock (GIL) must always\nbe held by the current thread to safely access Python objects. As a result,\nwhen Python calls into C++ via pybind11 the GIL must be held, and pybind11\nwill never implicitly release the GIL.\n\n.. code-block:: cpp\n\n void my_function() {\n /* GIL is held when this function is called from Python */\n }\n\n PYBIND11_MODULE(example, m) {\n m.def(\"my_function\", &my_function);\n }\n\npybind11 will ensure that the GIL is held when it knows that it is calling\nPython code. For example, if a Python callback is passed to C++ code via\n``std::function``, when C++ code calls the function the built-in wrapper\nwill acquire the GIL before calling the Python callback. Similarly, the\n``PYBIND11_OVERRIDE`` family of macros will acquire the GIL before calling\nback into Python.\n\nWhen writing C++ code that is called from other C++ code, if that code accesses\nPython state, it must explicitly acquire and release the GIL. A separate\ndocument on deadlocks [#f8]_ elaborates on a particularly subtle interaction\nwith C++'s block-scope static variable initializer guard mutexes.\n\n.. [#f8] See docs/advanced/deadlock.md\n\nThe classes :class:`gil_scoped_release` and :class:`gil_scoped_acquire` can be\nused to acquire and release the global interpreter lock in the body of a C++\nfunction call. In this way, long-running C++ code can be parallelized using\nmultiple Python threads, **but great care must be taken** when any\n:class:`gil_scoped_release` appear: if there is any way that the C++ code\ncan access Python objects, :class:`gil_scoped_acquire` should be used to\nreacquire the GIL. Taking :ref:`overriding_virtuals` as an example, this\ncould be realized as follows (important changes highlighted):\n\n.. code-block:: cpp\n :emphasize-lines: 8,30,31\n\n class PyAnimal : public Animal, public py::trampoline_self_life_support {\n public:\n /* Inherit the constructors */\n using Animal::Animal;\n\n /* Trampoline (need one for each virtual function) */\n std::string go(int n_times) {\n /* PYBIND11_OVERRIDE_PURE will acquire the GIL before accessing Python state */\n PYBIND11_OVERRIDE_PURE(\n std::string, /* Return type */\n Animal, /* Parent class */\n go, /* Name of function */\n n_times /* Argument(s) */\n );\n }\n };\n\n PYBIND11_MODULE(example, m) {\n py::class_ animal(m, \"Animal\");\n animal\n .def(py::init<>())\n .def(\"go\", &Animal::go);\n\n py::class_(m, \"Dog\", animal)\n .def(py::init<>());\n\n m.def(\"call_go\", [](Animal *animal) -> std::string {\n // GIL is held when called from Python code. Release GIL before\n // calling into (potentially long-running) C++ code\n py::gil_scoped_release release;\n return call_go(animal);\n });\n }\n\nThe ``call_go`` wrapper can also be simplified using the ``call_guard`` policy\n(see :ref:`call_policies`) which yields the same result:\n\n.. code-block:: cpp\n\n m.def(\"call_go\", &call_go, py::call_guard());\n\n\n.. _commongilproblems:\n\nCommon Sources Of Global Interpreter Lock Errors\n==================================================================\n\nFailing to properly hold the Global Interpreter Lock (GIL) is one of the\nmore common sources of bugs within code that uses pybind11. If you are\nrunning into GIL related errors, we highly recommend you consult the\nfollowing checklist.\n\n- Do you have any global variables that are pybind11 objects or invoke\n pybind11 functions in either their constructor or destructor? You are generally\n not allowed to invoke any Python function in a global static context. We recommend\n using lazy initialization and then intentionally leaking at the end of the program.\n\n- Do you have any pybind11 objects that are members of other C++ structures? One\n commonly overlooked requirement is that pybind11 objects have to increase their reference count\n whenever their copy constructor is called. Thus, you need to be holding the GIL to invoke\n the copy constructor of any C++ class that has a pybind11 member. This can sometimes be very\n tricky to track for complicated programs Think carefully when you make a pybind11 object\n a member in another struct.\n\n- C++ destructors that invoke Python functions can be particularly troublesome as\n destructors can sometimes get invoked in weird and unexpected circumstances as a result\n of exceptions.\n\n- C++ static block-scope variable initialization that calls back into Python can\n cause deadlocks; see [#f8]_ for a detailed discussion.\n\n- You should try running your code in a debug build. That will enable additional assertions\n within pybind11 that will throw exceptions on certain GIL handling errors\n (reference counting operations).\n\n.. _misc_free_threading:\n\nFree-threading support\n==================================================================\n\npybind11 supports the experimental free-threaded builds of Python versions 3.13+.\npybind11's internal data structures are thread safe. To enable your modules to be used with\nfree-threading, pass the :class:`mod_gil_not_used` tag as the third argument to\n``PYBIND11_MODULE``.\n\nFor example:\n\n.. code-block:: cpp\n :emphasize-lines: 1\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n py::class_ animal(m, \"Animal\");\n // etc\n }\n\nImportantly, enabling your module to be used with free-threading is also your promise that\nyour code is thread safe. Modules must still be built against the Python free-threading branch to\nenable free-threading, even if they specify this tag. Adding this tag does not break\ncompatibility with non-free-threaded Python.\n\n.. _misc_subinterp:\n\nSub-interpreter support\n==================================================================\n\npybind11 supports isolated sub-interpreters, which are stable in Python 3.12+. pybind11's\ninternal data structures are sub-interpreter safe. To enable your modules to be imported in\nisolated sub-interpreters, pass the :func:`multiple_interpreters::per_interpreter_gil()`\ntag as the third or later argument to ``PYBIND11_MODULE``.\n\nFor example:\n\n.. code-block:: cpp\n :emphasize-lines: 1\n\n PYBIND11_MODULE(example, m, py::multiple_interpreters::per_interpreter_gil()) {\n py::class_ animal(m, \"Animal\");\n // etc\n }\n\nBest Practices for Sub-interpreter Safety:\n\n- Your initialization function will run for each interpreter that imports your module.\n\n- Never share Python objects across different sub-interpreters.\n\n- Avoid global/static state whenever possible. Instead, keep state within each interpreter,\n such as in instance members tied to Python objects, :func:`globals()`, and the interpreter\n state dict.\n\n- Modules without any global/static state in their C++ code may already be sub-interpreter safe\n without any additional work!\n\n- Avoid trying to \"cache\" Python objects in C++ variables across function calls (this is an easy\n way to accidentally introduce sub-interpreter bugs).\n\n- While sub-interpreters each have their own GIL, there can now be multiple independent GILs in one\n program, so concurrent calls into a module from two different sub-interpreters are still\n possible. Therefore, your module still needs to consider thread safety.\n\npybind11 also supports \"legacy\" sub-interpreters which shared a single global GIL. You can enable\nlegacy-only behavior by using the :func:`multiple_interpreters::shared_gil()` tag in\n``PYBIND11_MODULE``.\n\nYou can explicitly disable sub-interpreter support in your module by using the\n:func:`multiple_interpreters::not_supported()` tag. This is the default behavior if you do not\nspecify a multiple_interpreters tag.\n\n.. _misc_concurrency:\n\nConcurrency and Parallelism in Python with pybind11\n===================================================\n\nSub-interpreter support does not imply free-threading support or vice versa. Free-threading safe\nmodules can still have global/static state (as long as access to them is thread-safe), but\nsub-interpreter safe modules cannot. Likewise, sub-interpreter safe modules can still rely on the\nGIL, but free-threading safe modules cannot.\n\nHere is a simple example module which has a function that calculates a value and returns the result\nof the previous calculation.\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m) {\n static size_t seed = 0;\n m.def(\"calc_next\", []() {\n auto old = seed;\n seed = (seed + 1) * 10;\n return old;\n });\n\nThis module is not free-threading safe because there is no synchronization on the number variable.\nIt is relatively easy to make this free-threading safe. One way is by using atomics, like this:\n\n.. code-block:: cpp\n :emphasize-lines: 1,2\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n static std::atomic seed(0);\n m.def(\"calc_next\", []() {\n size_t old, next;\n do {\n old = seed.load();\n next = (old + 1) * 10;\n } while (!seed.compare_exchange_weak(old, next));\n return old;\n });\n }\n\nThe atomic variable and the compare-exchange guarantee a consistent behavior from this function even\nwhen called currently from multiple threads at the same time.\n\nHowever, the global/static integer is not sub-interpreter safe, because the calls in one\nsub-interpreter will change what is seen in another. To fix it, the state needs to be specific to\neach interpreter. One way to do that is by storing the state on another Python object, such as a\nmember of a class. For this simple example, we will store it in :func:`globals`.\n\n.. code-block:: cpp\n :emphasize-lines: 1,6\n\n PYBIND11_MODULE(example, m, py::multiple_interpreters::per_interpreter_gil()) {\n m.def(\"calc_next\", []() {\n if (!py::globals().contains(\"myseed\"))\n py::globals()[\"myseed\"] = 0;\n size_t old = py::globals()[\"myseed\"];\n py::globals()[\"myseed\"] = (old + 1) * 10;\n return old;\n });\n }\n\nThis module is sub-interpreter safe, for both ``shared_gil`` (\"legacy\") and\n``per_interpreter_gil`` (\"default\") varieties. Multiple sub-interpreters could each call this same\nfunction concurrently from different threads. This is safe because each sub-interpreter's GIL\nprotects it's own Python objects from concurrent access.\n\nHowever, the module is no longer free-threading safe, for the same reason as\nbefore, because the calculation is not synchronized. We can synchronize it\nusing a Python critical section. This will do nothing if not in free-threaded\nPython. You can have it lock one or two Python objects. You cannot nest it.\n\n.. warning::\n\n When using a ``py::scoped_critical_section``, make sure it is not nested and\n that no other synchronization primitives (such as a ``std::mutex``) are\n held, which could lead to deadlocks. In 3.13, taking the same lock causes it\n to release then reacquire, which means you can't use it to, for example, read\n and write to a dictionary, because the dictionary uses a critical section\n internally in CPython. Use a ``std::mutex`` instead if you need this on\n Python 3.13. In 3.14, taking a lock on a locked object no longer releases\n and relocks as an optimization, which also fixes this case.\n\n.. code-block:: cpp\n :emphasize-lines: 1,4,8\n\n #include \n // ...\n\n PYBIND11_MODULE(example, m, py::multiple_interpreters::per_interpreter_gil(), py::mod_gil_not_used()) {\n m.def(\"calc_next\", []() {\n size_t old;\n py::dict g = py::globals();\n py::scoped_critical_section guard(g);\n if (!g.contains(\"myseed\"))\n g[\"myseed\"] = 0;\n old = g[\"myseed\"];\n g[\"myseed\"] = (old + 1) * 10;\n return old;\n });\n }\n\nThe module is now both sub-interpreter safe and free-threading safe.\n\nBinding sequence data types, iterators, the slicing protocol, etc.\n==================================================================\n\nPlease refer to the supplemental example for details.\n\n.. seealso::\n\n The file :file:`tests/test_sequences_and_iterators.cpp` contains a\n complete example that shows how to bind a sequence data type, including\n length queries (``__len__``), iterators (``__iter__``), the slicing\n protocol and other kinds of useful operations.\n\n\nPartitioning code over multiple extension modules\n=================================================\n\nIt's straightforward to split binding code over multiple extension modules,\nwhile referencing types that are declared elsewhere. Everything \"just\" works\nwithout any special precautions. One exception to this rule occurs when\nextending a type declared in another extension module. Recall the basic example\nfrom Section :ref:`inheritance`.\n\n.. code-block:: cpp\n\n py::class_ pet(m, \"Pet\");\n pet.def(py::init())\n .def_readwrite(\"name\", &Pet::name);\n\n py::class_(m, \"Dog\", pet /* <- specify parent */)\n .def(py::init())\n .def(\"bark\", &Dog::bark);\n\nSuppose now that ``Pet`` bindings are defined in a module named ``basic``,\nwhereas the ``Dog`` bindings are defined somewhere else. The challenge is of\ncourse that the variable ``pet`` is not available anymore though it is needed\nto indicate the inheritance relationship to the constructor of ``py::class_``.\nHowever, it can be acquired as follows:\n\n.. code-block:: cpp\n\n py::object pet = (py::object) py::module_::import(\"basic\").attr(\"Pet\");\n\n py::class_(m, \"Dog\", pet)\n .def(py::init())\n .def(\"bark\", &Dog::bark);\n\nAlternatively, you can specify the base class as a template parameter option to\n``py::class_``, which performs an automated lookup of the corresponding Python\ntype. Like the above code, however, this also requires invoking the ``import``\nfunction once to ensure that the pybind11 binding code of the module ``basic``\nhas been executed:\n\n.. code-block:: cpp\n\n py::module_::import(\"basic\");\n\n py::class_(m, \"Dog\")\n .def(py::init())\n .def(\"bark\", &Dog::bark);\n\nNaturally, both methods will fail when there are cyclic dependencies.\n\nNote that pybind11 code compiled with hidden-by-default symbol visibility (e.g.\nvia the command line flag ``-fvisibility=hidden`` on GCC/Clang), which is\nrequired for proper pybind11 functionality, can interfere with the ability to\naccess types defined in another extension module. Working around this requires\nmanually exporting types that are accessed by multiple extension modules;\npybind11 provides a macro to do just this:\n\n.. code-block:: cpp\n\n class PYBIND11_EXPORT Dog : public Animal {\n ...\n };\n\nNote also that it is possible (although would rarely be required) to share arbitrary\nC++ objects between extension modules at runtime. Internal library data is shared\nbetween modules using capsule machinery [#f6]_ which can be also utilized for\nstoring, modifying and accessing user-defined data. Note that an extension module\nwill \"see\" other extensions' data if and only if they were built with the same\npybind11 version. Consider the following example:\n\n.. code-block:: cpp\n\n auto data = reinterpret_cast(py::get_shared_data(\"mydata\"));\n if (!data)\n data = static_cast(py::set_shared_data(\"mydata\", new MyData(42)));\n\nIf the above snippet was used in several separately compiled extension modules,\nthe first one to be imported would create a ``MyData`` instance and associate\na ``\"mydata\"`` key with a pointer to it. Extensions that are imported later\nwould be then able to access the data behind the same pointer.\n\n.. [#f6] https://docs.python.org/3/extending/extending.html#using-capsules\n\nModule Destructors\n==================\n\npybind11 does not provide an explicit mechanism to invoke cleanup code at\nmodule destruction time. In rare cases where such functionality is required, it\nis possible to emulate it using Python capsules or weak references with a\ndestruction callback.\n\n.. code-block:: cpp\n\n auto cleanup_callback = []() {\n // perform cleanup here -- this function is called with the GIL held\n };\n\n m.add_object(\"_cleanup\", py::capsule(cleanup_callback));\n\nThis approach has the potential downside that instances of classes exposed\nwithin the module may still be alive when the cleanup callback is invoked\n(whether this is acceptable will generally depend on the application).\n\nAlternatively, the capsule may also be stashed within a type object, which\nensures that it not called before all instances of that type have been\ncollected:\n\n.. code-block:: cpp\n\n auto cleanup_callback = []() { /* ... */ };\n m.attr(\"BaseClass\").attr(\"_cleanup\") = py::capsule(cleanup_callback);\n\nBoth approaches also expose a potentially dangerous ``_cleanup`` attribute in\nPython, which may be undesirable from an API standpoint (a premature explicit\ncall from Python might lead to undefined behavior). Yet another approach that\navoids this issue involves weak reference with a cleanup callback:\n\n.. code-block:: cpp\n\n // Register a callback function that is invoked when the BaseClass object is collected\n py::cpp_function cleanup_callback(\n [](py::handle weakref) {\n // perform cleanup here -- this function is called with the GIL held\n\n weakref.dec_ref(); // release weak reference\n }\n );\n\n // Create a weak reference with a cleanup callback and initially leak it\n (void) py::weakref(m.attr(\"BaseClass\"), cleanup_callback).release();\n\n.. note::\n\n PyPy does not garbage collect objects when the interpreter exits. An alternative\n approach (which also works on CPython) is to use the :py:mod:`atexit` module [#f7]_,\n for example:\n\n .. code-block:: cpp\n\n auto atexit = py::module_::import(\"atexit\");\n atexit.attr(\"register\")(py::cpp_function([]() {\n // perform cleanup here -- this function is called with the GIL held\n }));\n\n .. [#f7] https://docs.python.org/3/library/atexit.html\n\n\nGenerating documentation using Sphinx\n=====================================\n\nSphinx [#f4]_ has the ability to inspect the signatures and documentation\nstrings in pybind11-based extension modules to automatically generate beautiful\ndocumentation in a variety formats. The python_example repository [#f5]_ contains a\nsimple example repository which uses this approach.\n\nThere are two potential gotchas when using this approach: first, make sure that\nthe resulting strings do not contain any :kbd:`TAB` characters, which break the\ndocstring parsing routines. You may want to use C++11 raw string literals,\nwhich are convenient for multi-line comments. Conveniently, any excess\nindentation will be automatically be removed by Sphinx. However, for this to\nwork, it is important that all lines are indented consistently, i.e.:\n\n.. code-block:: cpp\n\n // ok\n m.def(\"foo\", &foo, R\"mydelimiter(\n The foo function\n\n Parameters\n ----------\n )mydelimiter\");\n\n // *not ok*\n m.def(\"foo\", &foo, R\"mydelimiter(The foo function\n\n Parameters\n ----------\n )mydelimiter\");\n\nBy default, pybind11 automatically generates and prepends a signature to the docstring of a function\nregistered with ``module_::def()`` and ``class_::def()``. Sometimes this\nbehavior is not desirable, because you want to provide your own signature or remove\nthe docstring completely to exclude the function from the Sphinx documentation.\nThe class ``options`` allows you to selectively suppress auto-generated signatures:\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m) {\n py::options options;\n options.disable_function_signatures();\n\n m.def(\"add\", [](int a, int b) { return a + b; }, \"A function which adds two numbers\");\n }\n\npybind11 also appends all members of an enum to the resulting enum docstring.\nThis default behavior can be disabled by using the ``disable_enum_members_docstring()``\nfunction of the ``options`` class.\n\nWith ``disable_user_defined_docstrings()`` all user defined docstrings of\n``module_::def()``, ``class_::def()`` and ``enum_()`` are disabled, but the\nfunction signatures and enum members are included in the docstring, unless they\nare disabled separately.\n\nNote that changes to the settings affect only function bindings created during the\nlifetime of the ``options`` instance. When it goes out of scope at the end of the module's init function,\nthe default settings are restored to prevent unwanted side effects.\n\n.. [#f4] http://www.sphinx-doc.org\n.. [#f5] http://github.com/pybind/python_example\n\n.. _avoiding-cpp-types-in-docstrings:\n\nAvoiding C++ types in docstrings\n================================\n\nDocstrings are generated at the time of the declaration, e.g. when ``.def(...)`` is called.\nAt this point parameter and return types should be known to pybind11.\nIf a custom type is not exposed yet through a ``py::class_`` constructor or a custom type caster,\nits C++ type name will be used instead to generate the signature in the docstring:\n\n.. code-block:: text\n\n | __init__(...)\n | __init__(self: example.Foo, arg0: ns::Bar) -> None\n ^^^^^^^\n\n\nThis limitation can be circumvented by ensuring that C++ classes are registered with pybind11\nbefore they are used as a parameter or return type of a function:\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m) {\n\n auto pyFoo = py::class_(m, \"Foo\");\n auto pyBar = py::class_(m, \"Bar\");\n\n pyFoo.def(py::init());\n pyBar.def(py::init());\n }\n\nSetting inner type hints in docstrings\n======================================\n\nWhen you use pybind11 wrappers for ``list``, ``dict``, and other generic python\ntypes, the docstring will just display the generic type. You can convey the\ninner types in the docstring by using a special 'typed' version of the generic\ntype.\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m) {\n m.def(\"pass_list_of_str\", [](py::typing::List arg) {\n // arg can be used just like py::list\n ));\n }\n\nThe resulting docstring will be ``pass_list_of_str(arg0: list[str]) -> None``.\n\nThe following special types are available in ``pybind11/typing.h``:\n\n* ``py::Tuple``\n* ``py::Dict``\n* ``py::List``\n* ``py::Set``\n* ``py::Callable``\n\n.. warning:: Just like in python, these are merely hints. They don't actually\n enforce the types of their contents at runtime or compile time.\n" }, { "path": "docs/advanced/pycpp/index.rst", "content": "Python C++ interface\n####################\n\npybind11 exposes Python types and functions using thin C++ wrappers, which\nmakes it possible to conveniently call Python code from C++ without resorting\nto Python's C API.\n\n.. toctree::\n :maxdepth: 2\n\n object\n numpy\n utilities\n" }, { "path": "docs/advanced/pycpp/numpy.rst", "content": ".. _numpy:\n\nNumPy\n#####\n\nBuffer protocol\n===============\n\nPython supports an extremely general and convenient approach for exchanging\ndata between plugin libraries. Types can expose a buffer view [#f2]_, which\nprovides fast direct access to the raw internal data representation. Suppose we\nwant to bind the following simplistic Matrix class:\n\n.. code-block:: cpp\n\n class Matrix {\n public:\n Matrix(size_t rows, size_t cols) : m_rows(rows), m_cols(cols) {\n m_data = new float[rows*cols];\n }\n float *data() { return m_data; }\n size_t rows() const { return m_rows; }\n size_t cols() const { return m_cols; }\n private:\n size_t m_rows, m_cols;\n float *m_data;\n };\n\nThe following binding code exposes the ``Matrix`` contents as a buffer object,\nmaking it possible to cast Matrices into NumPy arrays. It is even possible to\ncompletely avoid copy operations with Python expressions like\n``np.array(matrix_instance, copy = False)``.\n\n.. code-block:: cpp\n\n py::class_(m, \"Matrix\", py::buffer_protocol())\n .def_buffer([](Matrix &m) -> py::buffer_info {\n return py::buffer_info(\n m.data(), /* Pointer to buffer */\n sizeof(float), /* Size of one scalar */\n py::format_descriptor::format(), /* Python struct-style format descriptor */\n 2, /* Number of dimensions */\n { m.rows(), m.cols() }, /* Buffer dimensions */\n { sizeof(float) * m.cols(), /* Strides (in bytes) for each index */\n sizeof(float) }\n );\n });\n\nSupporting the buffer protocol in a new type involves specifying the special\n``py::buffer_protocol()`` tag in the ``py::class_`` constructor and calling the\n``def_buffer()`` method with a lambda function that creates a\n``py::buffer_info`` description record on demand describing a given matrix\ninstance. The contents of ``py::buffer_info`` mirror the Python buffer protocol\nspecification.\n\n.. code-block:: cpp\n\n struct buffer_info {\n void *ptr;\n py::ssize_t itemsize;\n std::string format;\n py::ssize_t ndim;\n std::vector shape;\n std::vector strides;\n };\n\nTo create a C++ function that can take a Python buffer object as an argument,\nsimply use the type ``py::buffer`` as one of its arguments. Buffers can exist\nin a great variety of configurations, hence some safety checks are usually\nnecessary in the function body. Below, you can see a basic example on how to\ndefine a custom constructor for the Eigen double precision matrix\n(``Eigen::MatrixXd``) type, which supports initialization from compatible\nbuffer objects (e.g. a NumPy matrix).\n\n.. code-block:: cpp\n\n /* Bind MatrixXd (or some other Eigen type) to Python */\n typedef Eigen::MatrixXd Matrix;\n\n typedef Matrix::Scalar Scalar;\n constexpr bool rowMajor = Matrix::Flags & Eigen::RowMajorBit;\n\n py::class_(m, \"Matrix\", py::buffer_protocol())\n .def(py::init([](py::buffer b) {\n typedef Eigen::Stride Strides;\n\n /* Request a buffer descriptor from Python */\n py::buffer_info info = b.request();\n\n /* Some basic validation checks ... */\n if (!info.item_type_is_equivalent_to())\n throw std::runtime_error(\"Incompatible format: expected a double array!\");\n\n if (info.ndim != 2)\n throw std::runtime_error(\"Incompatible buffer dimension!\");\n\n auto strides = Strides(\n info.strides[rowMajor ? 0 : 1] / (py::ssize_t)sizeof(Scalar),\n info.strides[rowMajor ? 1 : 0] / (py::ssize_t)sizeof(Scalar));\n\n auto map = Eigen::Map(\n static_cast(info.ptr), info.shape[0], info.shape[1], strides);\n\n return Matrix(map);\n }));\n\nFor reference, the ``def_buffer()`` call for this Eigen data type should look\nas follows:\n\n.. code-block:: cpp\n\n .def_buffer([](Matrix &m) -> py::buffer_info {\n return py::buffer_info(\n m.data(), /* Pointer to buffer */\n sizeof(Scalar), /* Size of one scalar */\n py::format_descriptor::format(), /* Python struct-style format descriptor */\n 2, /* Number of dimensions */\n { m.rows(), m.cols() }, /* Buffer dimensions */\n { sizeof(Scalar) * (rowMajor ? m.cols() : 1),\n sizeof(Scalar) * (rowMajor ? 1 : m.rows()) }\n /* Strides (in bytes) for each index */\n );\n })\n\nFor a much easier approach of binding Eigen types (although with some\nlimitations), refer to the section on :doc:`/advanced/cast/eigen`.\n\n.. seealso::\n\n The file :file:`tests/test_buffers.cpp` contains a complete example\n that demonstrates using the buffer protocol with pybind11 in more detail.\n\n.. [#f2] http://docs.python.org/3/c-api/buffer.html\n\nArrays\n======\n\nBy exchanging ``py::buffer`` with ``py::array`` in the above snippet, we can\nrestrict the function so that it only accepts NumPy arrays (rather than any\ntype of Python object satisfying the buffer protocol).\n\nIn many situations, we want to define a function which only accepts a NumPy\narray of a certain data type. This is possible via the ``py::array_t``\ntemplate. For instance, the following function requires the argument to be a\nNumPy array containing double precision values.\n\n.. code-block:: cpp\n\n void f(py::array_t array);\n\nWhen it is invoked with a different type (e.g. an integer or a list of\nintegers), the binding code will attempt to cast the input into a NumPy array\nof the requested type. This feature requires the :file:`pybind11/numpy.h`\nheader to be included. Note that :file:`pybind11/numpy.h` does not depend on\nthe NumPy headers, and thus can be used without declaring a build-time\ndependency on NumPy; NumPy>=1.7.0 is a runtime dependency.\n\nData in NumPy arrays is not guaranteed to packed in a dense manner;\nfurthermore, entries can be separated by arbitrary column and row strides.\nSometimes, it can be useful to require a function to only accept dense arrays\nusing either the C (row-major) or Fortran (column-major) ordering. This can be\naccomplished via a second template argument with values ``py::array::c_style``\nor ``py::array::f_style``.\n\n.. code-block:: cpp\n\n void f(py::array_t array);\n\nThe ``py::array::forcecast`` argument is the default value of the second\ntemplate parameter, and it ensures that non-conforming arguments are converted\ninto an array satisfying the specified requirements instead of trying the next\nfunction overload.\n\nThere are several methods on arrays; the methods listed below under references\nwork, as well as the following functions based on the NumPy API:\n\n- ``.dtype()`` returns the type of the contained values.\n\n- ``.strides()`` returns a pointer to the strides of the array (optionally pass\n an integer axis to get a number).\n\n- ``.flags()`` returns the flag settings. ``.writable()`` and ``.owndata()``\n are directly available.\n\n- ``.offset_at()`` returns the offset (optionally pass indices).\n\n- ``.squeeze()`` returns a view with length-1 axes removed.\n\n- ``.view(dtype)`` returns a view of the array with a different dtype.\n\n- ``.reshape({i, j, ...})`` returns a view of the array with a different shape.\n ``.resize({...})`` is also available.\n\n- ``.index_at(i, j, ...)`` gets the count from the beginning to a given index.\n\n\nThere are also several methods for getting references (described below).\n\nStructured types\n================\n\nIn order for ``py::array_t`` to work with structured (record) types, we first\nneed to register the memory layout of the type. This can be done via\n``PYBIND11_NUMPY_DTYPE`` macro, called in the plugin definition code, which\nexpects the type followed by field names:\n\n.. code-block:: cpp\n\n struct A {\n int x;\n double y;\n };\n\n struct B {\n int z;\n A a;\n };\n\n // ...\n PYBIND11_MODULE(test, m, py::mod_gil_not_used()) {\n // ...\n\n PYBIND11_NUMPY_DTYPE(A, x, y);\n PYBIND11_NUMPY_DTYPE(B, z, a);\n /* now both A and B can be used as template arguments to py::array_t */\n }\n\nThe structure should consist of fundamental arithmetic types, ``std::complex``,\npreviously registered substructures, and arrays of any of the above. Both C++\narrays and ``std::array`` are supported. While there is a static assertion to\nprevent many types of unsupported structures, it is still the user's\nresponsibility to use only \"plain\" structures that can be safely manipulated as\nraw memory without violating invariants.\n\nScalar types\n============\n\nIn some cases we may want to accept or return NumPy scalar values such as\n``np.float32`` or ``np.float64``. We hope to be able to handle single-precision\nand double-precision on the C-side. However, both are bound to Python's\ndouble-precision builtin float by default, so they cannot be processed separately.\nWe used the ``py::buffer`` trick to implement the previous approach, which\nwill cause the readability of the code to drop significantly.\n\nLuckily, there's a helper type for this occasion - ``py::numpy_scalar``:\n\n.. code-block:: cpp\n\n m.def(\"add\", [](py::numpy_scalar a, py::numpy_scalar b) {\n return py::make_scalar(a + b);\n });\n m.def(\"add\", [](py::numpy_scalar a, py::numpy_scalar b) {\n return py::make_scalar(a + b);\n });\n\nThis type is trivially convertible to and from the type it wraps; currently\nsupported scalar types are NumPy arithmetic types: ``bool_``, ``int8``,\n``int16``, ``int32``, ``int64``, ``uint8``, ``uint16``, ``uint32``,\n``uint64``, ``float32``, ``float64``, ``complex64``, ``complex128``, all of\nthem mapping to respective C++ counterparts.\n\n.. note::\n\n ``py::numpy_scalar`` strictly matches NumPy scalar types. For example,\n ``py::numpy_scalar`` will accept ``np.int64(123)``,\n but **not** a regular Python ``int`` like ``123``.\n\n.. note::\n\n Native C types are mapped to NumPy types in a platform specific way: for\n instance, ``char`` may be mapped to either ``np.int8`` or ``np.uint8``\n and ``long`` may use 4 or 8 bytes depending on the platform. Unless you\n clearly understand the difference and your needs, please use ````.\n\nVectorizing functions\n=====================\n\nSuppose we want to bind a function with the following signature to Python so\nthat it can process arbitrary NumPy array arguments (vectors, matrices, general\nN-D arrays) in addition to its normal arguments:\n\n.. code-block:: cpp\n\n double my_func(int x, float y, double z);\n\nAfter including the ``pybind11/numpy.h`` header, this is extremely simple:\n\n.. code-block:: cpp\n\n m.def(\"vectorized_func\", py::vectorize(my_func));\n\nInvoking the function like below causes 4 calls to be made to ``my_func`` with\neach of the array elements. The significant advantage of this compared to\nsolutions like ``numpy.vectorize()`` is that the loop over the elements runs\nentirely on the C++ side and can be crunched down into a tight, optimized loop\nby the compiler. The result is returned as a NumPy array of type\n``numpy.dtype.float64``.\n\n.. code-block:: pycon\n\n >>> x = np.array([[1, 3], [5, 7]])\n >>> y = np.array([[2, 4], [6, 8]])\n >>> z = 3\n >>> result = vectorized_func(x, y, z)\n\nThe scalar argument ``z`` is transparently replicated 4 times. The input\narrays ``x`` and ``y`` are automatically converted into the right types (they\nare of type ``numpy.dtype.int64`` but need to be ``numpy.dtype.int32`` and\n``numpy.dtype.float32``, respectively).\n\n.. note::\n\n Only arithmetic, complex, and POD types passed by value or by ``const &``\n reference are vectorized; all other arguments are passed through as-is.\n Functions taking rvalue reference arguments cannot be vectorized.\n\nIn cases where the computation is too complicated to be reduced to\n``vectorize``, it will be necessary to create and access the buffer contents\nmanually. The following snippet contains a complete example that shows how this\nworks (the code is somewhat contrived, since it could have been done more\nsimply using ``vectorize``).\n\n.. code-block:: cpp\n\n #include \n #include \n\n namespace py = pybind11;\n\n py::array_t add_arrays(py::array_t input1, py::array_t input2) {\n py::buffer_info buf1 = input1.request(), buf2 = input2.request();\n\n if (buf1.ndim != 1 || buf2.ndim != 1)\n throw std::runtime_error(\"Number of dimensions must be one\");\n\n if (buf1.size != buf2.size)\n throw std::runtime_error(\"Input shapes must match\");\n\n /* No pointer is passed, so NumPy will allocate the buffer */\n auto result = py::array_t(buf1.size);\n\n py::buffer_info buf3 = result.request();\n\n double *ptr1 = static_cast(buf1.ptr);\n double *ptr2 = static_cast(buf2.ptr);\n double *ptr3 = static_cast(buf3.ptr);\n\n for (size_t idx = 0; idx < buf1.shape[0]; idx++)\n ptr3[idx] = ptr1[idx] + ptr2[idx];\n\n return result;\n }\n\n PYBIND11_MODULE(test, m, py::mod_gil_not_used()) {\n m.def(\"add_arrays\", &add_arrays, \"Add two NumPy arrays\");\n }\n\n.. seealso::\n\n The file :file:`tests/test_numpy_vectorize.cpp` contains a complete\n example that demonstrates using :func:`vectorize` in more detail.\n\nDirect access\n=============\n\nFor performance reasons, particularly when dealing with very large arrays, it\nis often desirable to directly access array elements without internal checking\nof dimensions and bounds on every access when indices are known to be already\nvalid. To avoid such checks, the ``array`` class and ``array_t`` template\nclass offer an unchecked proxy object that can be used for this unchecked\naccess through the ``unchecked`` and ``mutable_unchecked`` methods,\nwhere ``N`` gives the required dimensionality of the array:\n\n.. code-block:: cpp\n\n m.def(\"sum_3d\", [](py::array_t x) {\n auto r = x.unchecked<3>(); // x must have ndim = 3; can be non-writeable\n double sum = 0;\n for (py::ssize_t i = 0; i < r.shape(0); i++)\n for (py::ssize_t j = 0; j < r.shape(1); j++)\n for (py::ssize_t k = 0; k < r.shape(2); k++)\n sum += r(i, j, k);\n return sum;\n });\n m.def(\"increment_3d\", [](py::array_t x) {\n auto r = x.mutable_unchecked<3>(); // Will throw if ndim != 3 or flags.writeable is false\n for (py::ssize_t i = 0; i < r.shape(0); i++)\n for (py::ssize_t j = 0; j < r.shape(1); j++)\n for (py::ssize_t k = 0; k < r.shape(2); k++)\n r(i, j, k) += 1.0;\n }, py::arg().noconvert());\n\nTo obtain the proxy from an ``array`` object, you must specify both the data\ntype and number of dimensions as template arguments, such as ``auto r =\nmyarray.mutable_unchecked()``.\n\nIf the number of dimensions is not known at compile time, you can omit the\ndimensions template parameter (i.e. calling ``arr_t.unchecked()`` or\n``arr.unchecked()``. This will give you a proxy object that works in the\nsame way, but results in less optimizable code and thus a small efficiency\nloss in tight loops.\n\nNote that the returned proxy object directly references the array's data, and\nonly reads its shape, strides, and writeable flag when constructed. You must\ntake care to ensure that the referenced array is not destroyed or reshaped for\nthe duration of the returned object, typically by limiting the scope of the\nreturned instance.\n\nThe returned proxy object supports some of the same methods as ``py::array`` so\nthat it can be used as a drop-in replacement for some existing, index-checked\nuses of ``py::array``:\n\n- ``.ndim()`` returns the number of dimensions\n\n- ``.data(1, 2, ...)`` and ``r.mutable_data(1, 2, ...)``` returns a pointer to\n the ``const T`` or ``T`` data, respectively, at the given indices. The\n latter is only available to proxies obtained via ``a.mutable_unchecked()``.\n\n- ``.itemsize()`` returns the size of an item in bytes, i.e. ``sizeof(T)``.\n\n- ``.shape(n)`` returns the size of dimension ``n``\n\n- ``.size()`` returns the total number of elements (i.e. the product of the shapes).\n\n- ``.nbytes()`` returns the number of bytes used by the referenced elements\n (i.e. ``itemsize()`` times ``size()``).\n\n.. seealso::\n\n The file :file:`tests/test_numpy_array.cpp` contains additional examples\n demonstrating the use of this feature.\n\nEllipsis\n========\n\nPython provides a convenient ``...`` ellipsis notation that is often used to\nslice multidimensional arrays. For instance, the following snippet extracts the\nmiddle dimensions of a tensor with the first and last index set to zero.\n\n.. code-block:: python\n\n a = ... # a NumPy array\n b = a[0, ..., 0]\n\nThe function ``py::ellipsis()`` function can be used to perform the same\noperation on the C++ side:\n\n.. code-block:: cpp\n\n py::array a = /* A NumPy array */;\n py::array b = a[py::make_tuple(0, py::ellipsis(), 0)];\n\n\nMemory view\n===========\n\nFor a case when we simply want to provide a direct accessor to C/C++ buffer\nwithout a concrete class object, we can return a ``memoryview`` object. Suppose\nwe wish to expose a ``memoryview`` for 2x4 uint8_t array, we can do the\nfollowing:\n\n.. code-block:: cpp\n\n const uint8_t buffer[] = {\n 0, 1, 2, 3,\n 4, 5, 6, 7\n };\n m.def(\"get_memoryview2d\", []() {\n return py::memoryview::from_buffer(\n buffer, // buffer pointer\n { 2, 4 }, // shape (rows, cols)\n { sizeof(uint8_t) * 4, sizeof(uint8_t) } // strides in bytes\n );\n });\n\nThis approach is meant for providing a ``memoryview`` for a C/C++ buffer not\nmanaged by Python. The user is responsible for managing the lifetime of the\nbuffer. Using a ``memoryview`` created in this way after deleting the buffer in\nC++ side results in undefined behavior.\n\nWe can also use ``memoryview::from_memory`` for a simple 1D contiguous buffer:\n\n.. code-block:: cpp\n\n m.def(\"get_memoryview1d\", []() {\n return py::memoryview::from_memory(\n buffer, // buffer pointer\n sizeof(uint8_t) * 8 // buffer size\n );\n });\n\n.. versionchanged:: 2.6\n ``memoryview::from_memory`` added.\n" }, { "path": "docs/advanced/pycpp/object.rst", "content": "Python types\n############\n\n.. _wrappers:\n\nAvailable wrappers\n==================\n\nAll major Python types are available as thin C++ wrapper classes. These\ncan also be used as function parameters -- see :ref:`python_objects_as_args`.\n\nAvailable types include :class:`handle`, :class:`object`, :class:`bool_`,\n:class:`int_`, :class:`float_`, :class:`str`, :class:`bytes`, :class:`tuple`,\n:class:`list`, :class:`dict`, :class:`slice`, :class:`none`, :class:`capsule`,\n:class:`iterable`, :class:`iterator`, :class:`function`, :class:`buffer`,\n:class:`array`, and :class:`array_t`.\n\n.. warning::\n\n Be sure to review the :ref:`pytypes_gotchas` before using this heavily in\n your C++ API.\n\n.. _instantiating_compound_types:\n\nInstantiating compound Python types from C++\n============================================\n\nDictionaries can be initialized in the :class:`dict` constructor:\n\n.. code-block:: cpp\n\n using namespace pybind11::literals; // to bring in the `_a` literal\n py::dict d(\"spam\"_a=py::none(), \"eggs\"_a=42);\n\nA tuple of python objects can be instantiated using :func:`py::make_tuple`:\n\n.. code-block:: cpp\n\n py::tuple tup = py::make_tuple(42, py::none(), \"spam\");\n\nEach element is converted to a supported Python type.\n\nA `simple namespace`_ can be instantiated using\n\n.. code-block:: cpp\n\n using namespace pybind11::literals; // to bring in the `_a` literal\n py::object SimpleNamespace = py::module_::import(\"types\").attr(\"SimpleNamespace\");\n py::object ns = SimpleNamespace(\"spam\"_a=py::none(), \"eggs\"_a=42);\n\nAttributes on a namespace can be modified with the :func:`py::delattr`,\n:func:`py::getattr`, and :func:`py::setattr` functions. Simple namespaces can\nbe useful as lightweight stand-ins for class instances.\n\n.. _simple namespace: https://docs.python.org/3/library/types.html#types.SimpleNamespace\n\n.. _casting_back_and_forth:\n\nCasting back and forth\n======================\n\nIn this kind of mixed code, it is often necessary to convert arbitrary C++\ntypes to Python, which can be done using :func:`py::cast`:\n\n.. code-block:: cpp\n\n MyClass *cls = ...;\n py::object obj = py::cast(cls);\n\nThe reverse direction uses the following syntax:\n\n.. code-block:: cpp\n\n py::object obj = ...;\n MyClass *cls = obj.cast();\n\nWhen conversion fails, both directions throw the exception :class:`cast_error`.\n\n.. _python_libs:\n\nAccessing Python libraries from C++\n===================================\n\nIt is also possible to import objects defined in the Python standard\nlibrary or available in the current Python environment (``sys.path``) and work\nwith these in C++.\n\nThis example obtains a reference to the Python ``Decimal`` class.\n\n.. code-block:: cpp\n\n // Equivalent to \"from decimal import Decimal\"\n py::object Decimal = py::module_::import(\"decimal\").attr(\"Decimal\");\n\n.. code-block:: cpp\n\n // Try to import scipy\n py::object scipy = py::module_::import(\"scipy\");\n return scipy.attr(\"__version__\");\n\n\n.. _calling_python_functions:\n\nCalling Python functions\n========================\n\nIt is also possible to call Python classes, functions and methods\nvia ``operator()``.\n\n.. code-block:: cpp\n\n // Construct a Python object of class Decimal\n py::object pi = Decimal(\"3.14159\");\n\n.. code-block:: cpp\n\n // Use Python to make our directories\n py::object os = py::module_::import(\"os\");\n py::object makedirs = os.attr(\"makedirs\");\n makedirs(\"/tmp/path/to/somewhere\");\n\nOne can convert the result obtained from Python to a pure C++ version\nif a ``py::class_`` or type conversion is defined.\n\n.. code-block:: cpp\n\n py::function f = <...>;\n py::object result_py = f(1234, \"hello\", some_instance);\n MyClass &result = result_py.cast();\n\n.. _calling_python_methods:\n\nCalling Python methods\n========================\n\nTo call an object's method, one can again use ``.attr`` to obtain access to the\nPython method.\n\n.. code-block:: cpp\n\n // Calculate e^π in decimal\n py::object exp_pi = pi.attr(\"exp\")();\n py::print(py::str(exp_pi));\n\nIn the example above ``pi.attr(\"exp\")`` is a *bound method*: it will always call\nthe method for that same instance of the class. Alternately one can create an\n*unbound method* via the Python class (instead of instance) and pass the ``self``\nobject explicitly, followed by other arguments.\n\n.. code-block:: cpp\n\n py::object decimal_exp = Decimal.attr(\"exp\");\n\n // Compute the e^n for n=0..4\n for (int n = 0; n < 5; n++) {\n py::print(decimal_exp(Decimal(n));\n }\n\nKeyword arguments\n=================\n\nKeyword arguments are also supported. In Python, there is the usual call syntax:\n\n.. code-block:: python\n\n def f(number, say, to):\n ... # function code\n\n\n f(1234, say=\"hello\", to=some_instance) # keyword call in Python\n\nIn C++, the same call can be made using:\n\n.. code-block:: cpp\n\n using namespace pybind11::literals; // to bring in the `_a` literal\n f(1234, \"say\"_a=\"hello\", \"to\"_a=some_instance); // keyword call in C++\n\nUnpacking arguments\n===================\n\nUnpacking of ``*args`` and ``**kwargs`` is also possible and can be mixed with\nother arguments:\n\n.. code-block:: cpp\n\n // * unpacking\n py::tuple args = py::make_tuple(1234, \"hello\", some_instance);\n f(*args);\n\n // ** unpacking\n py::dict kwargs = py::dict(\"number\"_a=1234, \"say\"_a=\"hello\", \"to\"_a=some_instance);\n f(**kwargs);\n\n // mixed keywords, * and ** unpacking\n py::tuple args = py::make_tuple(1234);\n py::dict kwargs = py::dict(\"to\"_a=some_instance);\n f(*args, \"say\"_a=\"hello\", **kwargs);\n\nGeneralized unpacking according to PEP448_ is also supported:\n\n.. code-block:: cpp\n\n py::dict kwargs1 = py::dict(\"number\"_a=1234);\n py::dict kwargs2 = py::dict(\"to\"_a=some_instance);\n f(**kwargs1, \"say\"_a=\"hello\", **kwargs2);\n\n.. seealso::\n\n The file :file:`tests/test_pytypes.cpp` contains a complete\n example that demonstrates passing native Python types in more detail. The\n file :file:`tests/test_callbacks.cpp` presents a few examples of calling\n Python functions from C++, including keywords arguments and unpacking.\n\n.. _PEP448: https://www.python.org/dev/peps/pep-0448/\n\n.. _implicit_casting:\n\nImplicit casting\n================\n\nWhen using the C++ interface for Python types, or calling Python functions,\nobjects of type :class:`object` are returned. It is possible to invoke implicit\nconversions to subclasses like :class:`dict`. The same holds for the proxy objects\nreturned by ``operator[]`` or ``obj.attr()``.\nCasting to subtypes improves code readability and allows values to be passed to\nC++ functions that require a specific subtype rather than a generic :class:`object`.\n\n.. code-block:: cpp\n\n #include \n using namespace pybind11::literals;\n\n py::module_ os = py::module_::import(\"os\");\n py::module_ path = py::module_::import(\"os.path\"); // like 'import os.path as path'\n py::module_ np = py::module_::import(\"numpy\"); // like 'import numpy as np'\n\n py::str curdir_abs = path.attr(\"abspath\")(path.attr(\"curdir\"));\n py::print(py::str(\"Current directory: \") + curdir_abs);\n py::dict environ = os.attr(\"environ\");\n py::print(environ[\"HOME\"]);\n py::array_t arr = np.attr(\"ones\")(3, \"dtype\"_a=\"float32\");\n py::print(py::repr(arr + py::int_(1)));\n\nThese implicit conversions are available for subclasses of :class:`object`; there\nis no need to call ``obj.cast()`` explicitly as for custom classes, see\n:ref:`casting_back_and_forth`.\n\n.. note::\n If a trivial conversion via move constructor is not possible, both implicit and\n explicit casting (calling ``obj.cast()``) will attempt a \"rich\" conversion.\n For instance, ``py::list env = os.attr(\"environ\");`` will succeed and is\n equivalent to the Python code ``env = list(os.environ)`` that produces a\n list of the dict keys.\n\n.. TODO: Adapt text once PR #2349 has landed\n\nHandling exceptions\n===================\n\nPython exceptions from wrapper classes will be thrown as a ``py::error_already_set``.\nSee :ref:`Handling exceptions from Python in C++\n` for more information on handling exceptions\nraised when calling C++ wrapper classes.\n\n.. _pytypes_gotchas:\n\nGotchas\n=======\n\nDefault-Constructed Wrappers\n----------------------------\n\nWhen a wrapper type is default-constructed, it is **not** a valid Python object (i.e. it is not ``py::none()``). It is simply the same as\n``PyObject*`` null pointer. To check for this, use\n``static_cast(my_wrapper)``.\n\nAssigning py::none() to wrappers\n--------------------------------\n\nYou may be tempted to use types like ``py::str`` and ``py::dict`` in C++\nsignatures (either pure C++, or in bound signatures), and assign them default\nvalues of ``py::none()``. However, in a best case scenario, it will fail fast\nbecause ``None`` is not convertible to that type (e.g. ``py::dict``), or in a\nworse case scenario, it will silently work but corrupt the types you want to\nwork with (e.g. ``py::str(py::none())`` will yield ``\"None\"`` in Python).\n" }, { "path": "docs/advanced/pycpp/utilities.rst", "content": "Utilities\n#########\n\nUsing Python's print function in C++\n====================================\n\nThe usual way to write output in C++ is using ``std::cout`` while in Python one\nwould use ``print``. Since these methods use different buffers, mixing them can\nlead to output order issues. To resolve this, pybind11 modules can use the\n:func:`py::print` function which writes to Python's ``sys.stdout`` for consistency.\n\nPython's ``print`` function is replicated in the C++ API including optional\nkeyword arguments ``sep``, ``end``, ``file``, ``flush``. Everything works as\nexpected in Python:\n\n.. code-block:: cpp\n\n py::print(1, 2.0, \"three\"); // 1 2.0 three\n py::print(1, 2.0, \"three\", \"sep\"_a=\"-\"); // 1-2.0-three\n\n auto args = py::make_tuple(\"unpacked\", true);\n py::print(\"->\", *args, \"end\"_a=\"<-\"); // -> unpacked True <-\n\n.. _ostream_redirect:\n\nCapturing standard output from ostream\n======================================\n\nOften, a library will use the streams ``std::cout`` and ``std::cerr`` to print,\nbut this does not play well with Python's standard ``sys.stdout`` and ``sys.stderr``\nredirection. Replacing a library's printing with ``py::print `` may not\nbe feasible. This can be fixed using a guard around the library function that\nredirects output to the corresponding Python streams:\n\n.. code-block:: cpp\n\n #include \n\n ...\n\n // Add a scoped redirect for your noisy code\n m.def(\"noisy_func\", []() {\n py::scoped_ostream_redirect stream(\n std::cout, // std::ostream&\n py::module_::import(\"sys\").attr(\"stdout\") // Python output\n );\n call_noisy_func();\n });\n\n.. warning::\n\n The implementation in ``pybind11/iostream.h`` is NOT thread safe. Multiple\n threads writing to a redirected ostream concurrently cause data races\n and potentially buffer overflows. Therefore it is currently a requirement\n that all (possibly) concurrent redirected ostream writes are protected by\n a mutex. #HelpAppreciated: Work on iostream.h thread safety. For more\n background see the discussions under\n `PR #2982 `_ and\n `PR #2995 `_.\n\nThis method respects flushes on the output streams and will flush if needed\nwhen the scoped guard is destroyed. This allows the output to be redirected in\nreal time, such as to a Jupyter notebook. The two arguments, the C++ stream and\nthe Python output, are optional, and default to standard output if not given. An\nextra type, ``py::scoped_estream_redirect ``, is identical\nexcept for defaulting to ``std::cerr`` and ``sys.stderr``; this can be useful with\n``py::call_guard``, which allows multiple items, but uses the default constructor:\n\n.. code-block:: cpp\n\n // Alternative: Call single function using call guard\n m.def(\"noisy_func\", &call_noisy_function,\n py::call_guard());\n\nThe redirection can also be done in Python with the addition of a context\nmanager, using the ``py::add_ostream_redirect() `` function:\n\n.. code-block:: cpp\n\n py::add_ostream_redirect(m, \"ostream_redirect\");\n\nThe name in Python defaults to ``ostream_redirect`` if no name is passed. This\ncreates the following context manager in Python:\n\n.. code-block:: python\n\n with ostream_redirect(stdout=True, stderr=True):\n noisy_function()\n\nIt defaults to redirecting both streams, though you can use the keyword\narguments to disable one of the streams if needed.\n\n.. note::\n\n The above methods will not redirect C-level output to file descriptors, such\n as ``fprintf``. For those cases, you'll need to redirect the file\n descriptors either directly in C or with Python's ``os.dup2`` function\n in an operating-system dependent way.\n\n.. _eval:\n\nEvaluating Python expressions from strings and files\n====================================================\n\npybind11 provides the ``eval``, ``exec`` and ``eval_file`` functions to evaluate\nPython expressions and statements. The following example illustrates how they\ncan be used.\n\n.. code-block:: cpp\n\n // At beginning of file\n #include \n\n ...\n\n // Evaluate in scope of main module\n py::object scope = py::module_::import(\"__main__\").attr(\"__dict__\");\n\n // Evaluate an isolated expression\n int result = py::eval(\"my_variable + 10\", scope).cast();\n\n // Evaluate a sequence of statements\n py::exec(\n \"print('Hello')\\n\"\n \"print('world!');\",\n scope);\n\n // Evaluate the statements in an separate Python file on disk\n py::eval_file(\"script.py\", scope);\n\nC++11 raw string literals are also supported and quite handy for this purpose.\nThe only requirement is that the first statement must be on a new line following\nthe raw string delimiter ``R\"(``, ensuring all lines have common leading indent:\n\n.. code-block:: cpp\n\n py::exec(R\"(\n x = get_answer()\n if x == 42:\n print('Hello World!')\n else:\n print('Bye!')\n )\", scope\n );\n\n.. note::\n\n `eval` and `eval_file` accept a template parameter that describes how the\n string/file should be interpreted. Possible choices include ``eval_expr``\n (isolated expression), ``eval_single_statement`` (a single statement, return\n value is always ``none``), and ``eval_statements`` (sequence of statements,\n return value is always ``none``). `eval` defaults to ``eval_expr``,\n `eval_file` defaults to ``eval_statements`` and `exec` is just a shortcut\n for ``eval``.\n" }, { "path": "docs/advanced/smart_ptrs.rst", "content": ".. _py_class_holder:\n\nSmart pointers & ``py::class_``\n###############################\n\nThe binding generator for classes, ``py::class_``, can be passed a template\ntype that denotes a special *holder* type that is used to manage references to\nthe object. If no such holder type template argument is given, the default for\na type ``T`` is ``std::unique_ptr``.\n\n.. note::\n\n A ``py::class_`` for a given C++ type ``T`` — and all its derived types —\n can only use a single holder type.\n\n\n.. _smart_holder:\n\n``py::smart_holder``\n====================\n\nStarting with pybind11v3, ``py::smart_holder`` is built into pybind11. It is\nthe recommended ``py::class_`` holder for most situations. However, for\nbackward compatibility it is **not** the default holder, and there are no\nplans to make it the default holder in the future.\n\nIt is extremely easy to use the safer and more versatile ``py::smart_holder``:\nsimply add ``py::smart_holder`` to ``py::class_``:\n\n* ``py::class_`` to\n\n* ``py::class_``.\n\n.. note::\n\n A shorthand, ``py::classh``, is provided for\n ``py::class_``. The ``h`` in ``py::classh`` stands\n for **smart_holder** but is shortened for brevity, ensuring it has the\n same number of characters as ``py::class_``. This design choice facilitates\n easy experimentation with ``py::smart_holder`` without introducing\n distracting whitespace noise in diffs.\n\nThe ``py::smart_holder`` functionality includes the following:\n\n* Support for **two-way** Python/C++ conversions for both\n ``std::unique_ptr`` and ``std::shared_ptr`` **simultaneously**.\n\n* Passing a Python object back to C++ via ``std::unique_ptr``, safely\n **disowning** the Python object.\n\n* Safely passing \"trampoline\" objects (objects with C++ virtual function\n overrides implemented in Python, see :ref:`overriding_virtuals`) via\n ``std::unique_ptr`` or ``std::shared_ptr`` back to C++:\n associated Python objects are automatically kept alive for the lifetime\n of the smart-pointer.\n\n* Full support for ``std::enable_shared_from_this`` (`cppreference\n `_).\n\n\n``std::unique_ptr``\n===================\n\nThis is the default ``py::class_`` holder and works as expected in\nmost situations. However, handling base-and-derived classes involves a\n``reinterpret_cast``, which is, strictly speaking, undefined behavior.\nAlso note that the ``std::unique_ptr`` holder only supports passing a\n``std::unique_ptr`` from C++ to Python, but not the other way around.\nFor example, the following code works as expected with ``py::class_``:\n\n.. code-block:: cpp\n\n std::unique_ptr create_example() { return std::unique_ptr(new Example()); }\n\n.. code-block:: cpp\n\n m.def(\"create_example\", &create_example);\n\nHowever, this will fail with ``py::class_`` (but works with\n``py::class_``):\n\n.. code-block:: cpp\n\n void do_something_with_example(std::unique_ptr ex) { ... }\n\n.. note::\n\n The ``reinterpret_cast`` mentioned above is `here\n `_.\n For completeness: The same cast is also applied to ``py::smart_holder``,\n but that is safe, because ``py::smart_holder`` is not templated.\n\n\n``std::shared_ptr``\n===================\n\nIt is possible to use ``std::shared_ptr`` as the holder, for example:\n\n.. code-block:: cpp\n\n py::class_ /* <- holder type */>(m, \"Example\");\n\nCompared to using ``py::class_``, there are two noteworthy disadvantages:\n\n* Because a ``py::class_`` for a given C++ type ``T`` can only use a\n single holder type, ``std::unique_ptr`` cannot even be passed from C++\n to Python. This will become apparent only at runtime, often through a\n segmentation fault.\n\n* Similar to the ``std::unique_ptr`` holder, the handling of base-and-derived\n classes involves a ``reinterpret_cast`` that has strictly speaking undefined\n behavior, although it works as expected in most situations.\n\n\n.. _smart_pointers:\n\nCustom smart pointers\n=====================\n\nFor custom smart pointers (e.g. ``c10::intrusive_ptr`` in pytorch), transparent\nconversions can be enabled using a macro invocation similar to the following.\nIt must be declared at the top namespace level before any binding code:\n\n.. code-block:: cpp\n\n PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr)\n\nThe first argument of :func:`PYBIND11_DECLARE_HOLDER_TYPE` should be a\nplaceholder name that is used as a template parameter of the second argument.\nThus, feel free to use any identifier, but use it consistently on both sides;\nalso, don't use the name of a type that already exists in your codebase.\n\nThe macro also accepts a third optional boolean parameter that is set to false\nby default. Specify\n\n.. code-block:: cpp\n\n PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr, true)\n\nif ``SmartPtr`` can always be initialized from a ``T*`` pointer without the\nrisk of inconsistencies (such as multiple independent ``SmartPtr`` instances\nbelieving that they are the sole owner of the ``T*`` pointer). A common\nsituation where ``true`` should be passed is when the ``T`` instances use\n*intrusive* reference counting.\n\nPlease take a look at the :ref:`macro_notes` before using this feature.\n\nBy default, pybind11 assumes that your custom smart pointer has a standard\ninterface, i.e. provides a ``.get()`` member function to access the underlying\nraw pointer. If this is not the case, pybind11's ``holder_helper`` must be\nspecialized:\n\n.. code-block:: cpp\n\n // Always needed for custom holder types\n PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr)\n\n // Only needed if the type's `.get()` goes by another name\n namespace PYBIND11_NAMESPACE { namespace detail {\n template \n struct holder_helper> { // <-- specialization\n static const T *get(const SmartPtr &p) { return p.getPointer(); }\n };\n }}\n\nThe above specialization informs pybind11 that the custom ``SmartPtr`` class\nprovides ``.get()`` functionality via ``.getPointer()``.\n\n.. note::\n\n The two noteworthy disadvantages mentioned under the ``std::shared_ptr``\n section apply similarly to custom smart pointer holders, but there is no\n established safe alternative in this case.\n\n.. seealso::\n\n The file :file:`tests/test_smart_ptr.cpp` contains a complete example\n that demonstrates how to work with custom reference-counting holder types\n in more detail.\n" }, { "path": "docs/basics.rst", "content": ".. _basics:\n\nFirst steps\n###########\n\nThis sections demonstrates the basic features of pybind11. Before getting\nstarted, make sure that development environment is set up to compile the\nincluded set of test cases.\n\n\nCompiling the test cases\n========================\n\nLinux/macOS\n-----------\n\nOn Linux you'll need to install the **python-dev** or **python3-dev** packages as\nwell as **cmake**. On macOS, the included python version works out of the box,\nbut **cmake** must still be installed.\n\nAfter installing the prerequisites, run\n\n.. code-block:: bash\n\n mkdir build\n cd build\n cmake ..\n make check -j 4\n\nThe last line will both compile and run the tests.\n\nWindows\n-------\n\nOn Windows, only **Visual Studio 2017** and newer are supported.\n\n.. Note::\n\n To use the C++17 in Visual Studio 2017 (MSVC 14.1), pybind11 requires the flag\n ``/permissive-`` to be passed to the compiler `to enforce standard conformance`_. When\n building with Visual Studio 2019, this is not strictly necessary, but still advised.\n\n.. _`to enforce standard conformance`: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=vs-2017\n\nTo compile and run the tests:\n\n.. code-block:: batch\n\n mkdir build\n cd build\n cmake ..\n cmake --build . --config Release --target check\n\nThis will create a Visual Studio project, compile and run the target, all from the\ncommand line.\n\n.. Note::\n\n If all tests fail, make sure that the Python binary and the testcases are compiled\n for the same processor type and bitness (i.e. either **i386** or **x86_64**). You\n can specify **x86_64** as the target architecture for the generated Visual Studio\n project using ``cmake -A x64 ..``.\n\n.. seealso::\n\n Advanced users who are already familiar with Boost.Python may want to skip\n the tutorial and look at the test cases in the :file:`tests` directory,\n which exercise all features of pybind11.\n\nHeader and namespace conventions\n================================\n\nFor brevity, all code examples assume that the following two lines are present:\n\n.. code-block:: cpp\n\n #include \n\n namespace py = pybind11;\n\n.. note::\n\n ``pybind11/pybind11.h`` includes ``Python.h``, as such it must be the first file\n included in any source file or header for `the same reasons as Python.h`_.\n\n.. _`the same reasons as Python.h`: https://docs.python.org/3/extending/extending.html#a-simple-example\n\nSome features may require additional headers, but those will be specified as needed.\n\n.. _simple_example:\n\nCreating bindings for a simple function\n=======================================\n\nLet's start by creating Python bindings for an extremely simple function, which\nadds two numbers and returns their result:\n\n.. code-block:: cpp\n\n int add(int i, int j) {\n return i + j;\n }\n\nFor simplicity [#f1]_, we'll put both this function and the binding code into\na file named :file:`example.cpp` with the following contents:\n\n.. code-block:: cpp\n\n #include \n\n namespace py = pybind11;\n\n int add(int i, int j) {\n return i + j;\n }\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n m.doc() = \"pybind11 example plugin\"; // optional module docstring\n\n m.def(\"add\", &add, \"A function that adds two numbers\");\n }\n\n.. [#f1] In practice, implementation and binding code will generally be located\n in separate files.\n\nThe :func:`PYBIND11_MODULE` macro creates a function that will be called when an\n``import`` statement is issued from within Python. The module name (``example``)\nis given as the first macro argument (it should not be in quotes). The second\nargument (``m``) defines a variable of type :class:`py::module_ ` which\nis the main interface for creating bindings. The method :func:`module_::def`\ngenerates binding code that exposes the ``add()`` function to Python.\n\n.. note::\n\n Notice how little code was needed to expose our function to Python: all\n details regarding the function's parameters and return value were\n automatically inferred using template metaprogramming. This overall\n approach and the used syntax are borrowed from Boost.Python, though the\n underlying implementation is very different.\n\npybind11 is a header-only library, hence it is not necessary to link against\nany special libraries and there are no intermediate (magic) translation steps.\nOn Linux, the above example can be compiled using the following command:\n\n.. code-block:: bash\n\n $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3 -m pybind11 --extension-suffix)\n\n.. note::\n\n If you used :ref:`include_as_a_submodule` to get the pybind11 source, then\n use ``$(python3-config --includes) -Iextern/pybind11/include`` instead of\n ``$(python3 -m pybind11 --includes)`` in the above compilation, as\n explained in :ref:`building_manually`.\n\nFor more details on the required compiler flags on Linux and macOS, see\n:ref:`building_manually`. For complete cross-platform compilation instructions,\nrefer to the :ref:`compiling` page.\n\nThe `python_example`_ and `cmake_example`_ repositories are also a good place\nto start. They are both complete project examples with cross-platform build\nsystems. The only difference between the two is that `python_example`_ uses\nPython's ``setuptools`` to build the module, while `cmake_example`_ uses CMake\n(which may be preferable for existing C++ projects).\n\n.. _python_example: https://github.com/pybind/python_example\n.. _cmake_example: https://github.com/pybind/cmake_example\n\nBuilding the above C++ code will produce a binary module file that can be\nimported to Python. Assuming that the compiled module is located in the\ncurrent directory, the following interactive Python session shows how to\nload and execute the example:\n\n.. code-block:: pycon\n\n $ python\n Python 3.9.10 (main, Jan 15 2022, 11:48:04)\n [Clang 13.0.0 (clang-1300.0.29.3)] on darwin\n Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n >>> import example\n >>> example.add(1, 2)\n 3\n >>>\n\n.. _keyword_args:\n\nKeyword arguments\n=================\n\nWith a simple code modification, it is possible to inform Python about the\nnames of the arguments (\"i\" and \"j\" in this case).\n\n.. code-block:: cpp\n\n m.def(\"add\", &add, \"A function which adds two numbers\",\n py::arg(\"i\"), py::arg(\"j\"));\n\n:class:`arg` is one of several special tag classes which can be used to pass\nmetadata into :func:`module_::def`. With this modified binding code, we can now\ncall the function using keyword arguments, which is a more readable alternative\nparticularly for functions taking many parameters:\n\n.. code-block:: pycon\n\n >>> import example\n >>> example.add(i=1, j=2)\n 3L\n\nThe keyword names also appear in the function signatures within the documentation.\n\n.. code-block:: pycon\n\n >>> help(example)\n\n ....\n\n FUNCTIONS\n add(...)\n Signature : (i: int, j: int) -> int\n\n A function which adds two numbers\n\nA shorter notation for named arguments is also available:\n\n.. code-block:: cpp\n\n // regular notation\n m.def(\"add1\", &add, py::arg(\"i\"), py::arg(\"j\"));\n // shorthand\n using namespace pybind11::literals;\n m.def(\"add2\", &add, \"i\"_a, \"j\"_a);\n\nThe :var:`_a` suffix forms a C++11 literal which is equivalent to :class:`arg`.\nNote that the literal operator must first be made visible with the directive\n``using namespace pybind11::literals``. This does not bring in anything else\nfrom the ``pybind11`` namespace except for literals.\n\n.. _default_args:\n\nDefault arguments\n=================\n\nSuppose now that the function to be bound has default arguments, e.g.:\n\n.. code-block:: cpp\n\n int add(int i = 1, int j = 2) {\n return i + j;\n }\n\nUnfortunately, pybind11 cannot automatically extract these parameters, since they\nare not part of the function's type information. However, they are simple to specify\nusing an extension of :class:`arg`:\n\n.. code-block:: cpp\n\n m.def(\"add\", &add, \"A function which adds two numbers\",\n py::arg(\"i\") = 1, py::arg(\"j\") = 2);\n\nThe default values also appear within the documentation.\n\n.. code-block:: pycon\n\n >>> help(example)\n\n ....\n\n FUNCTIONS\n add(...)\n Signature : (i: int = 1, j: int = 2) -> int\n\n A function which adds two numbers\n\nThe shorthand notation is also available for default arguments:\n\n.. code-block:: cpp\n\n // regular notation\n m.def(\"add1\", &add, py::arg(\"i\") = 1, py::arg(\"j\") = 2);\n // shorthand\n m.def(\"add2\", &add, \"i\"_a=1, \"j\"_a=2);\n\nExporting variables\n===================\n\nTo expose a value from C++, use the ``attr`` function to register it in a\nmodule as shown below. Built-in types and general objects (more on that later)\nare automatically converted when assigned as attributes, and can be explicitly\nconverted using the function ``py::cast``.\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n m.attr(\"the_answer\") = 42;\n py::object world = py::cast(\"World\");\n m.attr(\"what\") = world;\n }\n\nThese are then accessible from Python:\n\n.. code-block:: pycon\n\n >>> import example\n >>> example.the_answer\n 42\n >>> example.what\n 'World'\n\n.. _supported_types:\n\nSupported data types\n====================\n\nA large number of data types are supported out of the box and can be used\nseamlessly as functions arguments, return values or with ``py::cast`` in general.\nFor a full overview, see the :doc:`advanced/cast/index` section.\n" }, { "path": "docs/benchmark.py", "content": "from __future__ import annotations\n\nimport datetime as dt\nimport os\nimport random\n\nnfns = 4 # Functions per class\nnargs = 4 # Arguments per function\n\n\ndef generate_dummy_code_pybind11(nclasses=10):\n decl = \"\"\n bindings = \"\"\n\n for cl in range(nclasses):\n decl += f\"class cl{cl:03};\\n\"\n decl += \"\\n\"\n\n for cl in range(nclasses):\n decl += f\"class {cl:03} {{\\n\"\n decl += \"public:\\n\"\n bindings += f' py::class_(m, \"cl{cl:03}\")\\n'\n for fn in range(nfns):\n ret = random.randint(0, nclasses - 1)\n params = [random.randint(0, nclasses - 1) for i in range(nargs)]\n decl += f\" cl{ret:03} *fn_{fn:03}(\"\n decl += \", \".join(f\"cl{p:03} *\" for p in params)\n decl += \");\\n\"\n bindings += f' .def(\"fn_{fn:03}\", &cl{cl:03}::fn_{fn:03})\\n'\n decl += \"};\\n\\n\"\n bindings += \" ;\\n\"\n\n result = \"#include \\n\\n\"\n result += \"namespace py = pybind11;\\n\\n\"\n result += decl + \"\\n\"\n result += \"PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\\n\"\n result += bindings\n result += \"}\"\n return result\n\n\ndef generate_dummy_code_boost(nclasses=10):\n decl = \"\"\n bindings = \"\"\n\n for cl in range(nclasses):\n decl += f\"class cl{cl:03};\\n\"\n decl += \"\\n\"\n\n for cl in range(nclasses):\n decl += f\"class cl{cl:03} {{\\n\"\n decl += \"public:\\n\"\n bindings += f' py::class_(\"cl{cl:03}\")\\n'\n for fn in range(nfns):\n ret = random.randint(0, nclasses - 1)\n params = [random.randint(0, nclasses - 1) for i in range(nargs)]\n decl += f\" cl{ret:03} *fn_{fn:03}(\"\n decl += \", \".join(f\"cl{p:03} *\" for p in params)\n decl += \");\\n\"\n bindings += f' .def(\"fn_{fn:03}\", &cl{cl:03}::fn_{fn:03}, py::return_value_policy())\\n'\n decl += \"};\\n\\n\"\n bindings += \" ;\\n\"\n\n result = \"#include \\n\\n\"\n result += \"namespace py = boost::python;\\n\\n\"\n result += decl + \"\\n\"\n result += \"BOOST_PYTHON_MODULE(example) {\\n\"\n result += bindings\n result += \"}\"\n return result\n\n\nfor codegen in [generate_dummy_code_pybind11, generate_dummy_code_boost]:\n print(\"{\")\n for i in range(10):\n nclasses = 2**i\n with open(\"test.cpp\", \"w\") as f:\n f.write(codegen(nclasses))\n n1 = dt.datetime.now()\n os.system(\n \"g++ -Os -shared -rdynamic -undefined dynamic_lookup \"\n \"-fvisibility=hidden -std=c++14 test.cpp -I include \"\n \"-I /System/Library/Frameworks/Python.framework/Headers -o test.so\"\n )\n n2 = dt.datetime.now()\n elapsed = (n2 - n1).total_seconds()\n size = os.stat(\"test.so\").st_size\n print(f\" {{{nclasses * nfns}, {elapsed:.6f}, {size}}},\")\n print(\"}\")\n" }, { "path": "docs/benchmark.rst", "content": "Benchmark\n=========\n\nThe following is the result of a synthetic benchmark comparing both compilation\ntime and module size of pybind11 against Boost.Python. A detailed report about a\nBoost.Python to pybind11 conversion of a real project is available here: [#f1]_.\n\n.. [#f1] http://graylab.jhu.edu/RosettaCon2016/PyRosetta-4.pdf\n\nSetup\n-----\n\nA python script (see the ``docs/benchmark.py`` file) was used to generate a set\nof files with dummy classes whose count increases for each successive benchmark\n(between 1 and 2048 classes in powers of two). Each class has four methods with\na randomly generated signature with a return value and four arguments. (There\nwas no particular reason for this setup other than the desire to generate many\nunique function signatures whose count could be controlled in a simple way.)\n\nHere is an example of the binding code for one class:\n\n.. code-block:: cpp\n\n ...\n class cl034 {\n public:\n cl279 *fn_000(cl084 *, cl057 *, cl065 *, cl042 *);\n cl025 *fn_001(cl098 *, cl262 *, cl414 *, cl121 *);\n cl085 *fn_002(cl445 *, cl297 *, cl145 *, cl421 *);\n cl470 *fn_003(cl200 *, cl323 *, cl332 *, cl492 *);\n };\n ...\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n ...\n py::class_(m, \"cl034\")\n .def(\"fn_000\", &cl034::fn_000)\n .def(\"fn_001\", &cl034::fn_001)\n .def(\"fn_002\", &cl034::fn_002)\n .def(\"fn_003\", &cl034::fn_003)\n ...\n }\n\nThe Boost.Python version looks almost identical except that a return value\npolicy had to be specified as an argument to ``def()``. For both libraries,\ncompilation was done with\n\n.. code-block:: bash\n\n Apple LLVM version 7.0.2 (clang-700.1.81)\n\nand the following compilation flags\n\n.. code-block:: bash\n\n g++ -Os -shared -rdynamic -undefined dynamic_lookup -fvisibility=hidden -std=c++14\n\nCompilation time\n----------------\n\nThe following log-log plot shows how the compilation time grows for an\nincreasing number of class and function declarations. pybind11 includes many\nfewer headers, which initially leads to shorter compilation times, but the\nperformance is ultimately fairly similar (pybind11 is 19.8 seconds faster for\nthe largest largest file with 2048 classes and a total of 8192 methods -- a\nmodest **1.2x** speedup relative to Boost.Python, which required 116.35\nseconds).\n\n.. only:: not latex\n\n .. image:: pybind11_vs_boost_python1.svg\n\n.. only:: latex\n\n .. image:: pybind11_vs_boost_python1.png\n\nModule size\n-----------\n\nDifferences between the two libraries become much more pronounced when\nconsidering the file size of the generated Python plugin: for the largest file,\nthe binary generated by Boost.Python required 16.8 MiB, which was **2.17\ntimes** / **9.1 megabytes** larger than the output generated by pybind11. For\nvery small inputs, Boost.Python has an edge in the plot below -- however, note\nthat it stores many definitions in an external library, whose size was not\nincluded here, hence the comparison is slightly shifted in Boost.Python's\nfavor.\n\n.. only:: not latex\n\n .. image:: pybind11_vs_boost_python2.svg\n\n.. only:: latex\n\n .. image:: pybind11_vs_boost_python2.png\n" }, { "path": "docs/changelog.md", "content": "# Changelog\n\n\n\nStarting with version 1.8.0, pybind11 releases use a [semantic\nversioning](http://semver.org) policy.\n\nChanges will be added here periodically from the \"Suggested changelog\nentry\" block in pull request descriptions.\n\n\n## Version 3.0.2 (February 16, 2026)\n\nNew Features:\n\n- Added helper functions to `py::array` that return shape and strides as `std::span` when available.\n [#5974](https://github.com/pybind/pybind11/pull/5974)\n\nBug fixes:\n\n- Added fallback locking for Python 3.13t where `PyCriticalSection_BeginMutex` is unavailable.\n [#5981](https://github.com/pybind/pybind11/pull/5981)\n\n- Fixed race condition in `py::make_key_iterator` with free-threaded Python.\n [#5971](https://github.com/pybind/pybind11/pull/5971)\n\n- MSVC 19.16 and earlier were blocked from using `std::launder` due to internal compiler errors.\n [#5968](https://github.com/pybind/pybind11/pull/5968)\n\n- Internals destructors were updated to check the owning interpreter before clearing Python objects.\n [#5965](https://github.com/pybind/pybind11/pull/5965)\n\n- Internals shutdown handling was refined in two iterations before release: an initial finalization-time cleanup was followed by a safety adjustment to avoid late-shutdown `py::cast` segfaults.\n [#5958](https://github.com/pybind/pybind11/pull/5958)\n [#5972](https://github.com/pybind/pybind11/pull/5972)\n\n- Fixed ambiguous `str(handle)` construction for `object`-derived types like `kwargs` or `dict` by templatizing the constructor with SFINAE.\n [#5949](https://github.com/pybind/pybind11/pull/5949)\n\n- Fixed concurrency consistency for `internals_pp_manager` under multiple-interpreters.\n [#5947](https://github.com/pybind/pybind11/pull/5947)\n\n- Fixed MSVC LNK2001 in C++20 builds when /GL (whole program optimization) is enabled.\n [#5939](https://github.com/pybind/pybind11/pull/5939)\n\n- Added per-interpreter storage for `gil_safe_call_once_and_store` to make it safe under multi-interpreters.\n [#5933](https://github.com/pybind/pybind11/pull/5933)\n\n- A workaround for a GCC `-Warray-bounds` false positive in `argument_vector` was added.\n [#5908](https://github.com/pybind/pybind11/pull/5908)\n\n- Corrected a mistake where support for `__index__` was added, but the type hints did not reflect acceptance of `SupportsIndex` objects. Also fixed a long-standing bug: the complex-caster did not accept `__index__` in `convert` mode.\n [#5891](https://github.com/pybind/pybind11/pull/5891)\n\n- Fixed `*args/**kwargs` return types. Added type hinting to `py::make_tuple`.\n [#5881](https://github.com/pybind/pybind11/pull/5881)\n\n- Fixed compiler error in `type_caster_generic` when casting a `T` implicitly convertible from `T*`.\n [#5873](https://github.com/pybind/pybind11/pull/5873)\n\n- Updated `py::native_enum` bindings to unregister enum types on destruction, preventing a use-after-free when returning a destroyed enum instance.\n [#5871](https://github.com/pybind/pybind11/pull/5871)\n\n- Fixed undefined behavior that occurred when importing pybind11 modules from non-main threads created by C API modules or embedded python interpreters.\n [#5870](https://github.com/pybind/pybind11/pull/5870)\n\n- Fixed dangling pointer in `internals::registered_types_cpp_fast`.\n [#5867](https://github.com/pybind/pybind11/pull/5867)\n\n- Added support for `std::shared_ptr` when loading module-local or conduit types from other modules.\n [#5862](https://github.com/pybind/pybind11/pull/5862)\n\n- Fixed thread-safety issues if types were concurrently registered while `get_local_type_info()` was called in free threaded Python.\n [#5856](https://github.com/pybind/pybind11/pull/5856)\n\n- Fixed py::float_ casting and py::int_ and py::float_ type hints.\n [#5839](https://github.com/pybind/pybind11/pull/5839)\n\n- Fixed two `smart_holder` bugs in `shared_ptr` and `unique_ptr` adoption with multiple/virtual inheritance:\n - `shared_ptr` to-Python caster was updated to register the correct subobject pointer (fixes #5786).\n - `unique_ptr` adoption was updated to own the proper object start while aliasing subobject pointers for registration, which fixed MSVC crashes during destruction.\n [#5836](https://github.com/pybind/pybind11/pull/5836)\n\n- Constrained `accessor::operator=` templates to avoid obscuring special members.\n [#5832](https://github.com/pybind/pybind11/pull/5832)\n\n- Fixed crash that can occur when finalizers acquire and release the GIL.\n [#5828](https://github.com/pybind/pybind11/pull/5828)\n\n- Fixed compiler detection in `pybind11/detail/pybind11_namespace_macros.h` for clang-cl on Windows, to address warning suppression macros.\n [#5816](https://github.com/pybind/pybind11/pull/5816)\n\n- Fixed compatibility with CMake policy CMP0190 by not always requiring a Python interpreter when cross-compiling.\n [#5829](https://github.com/pybind/pybind11/pull/5829)\n\n- Added a static assertion to disallow `keep_alive` and `call_guard` on properties.\n [#5533](https://github.com/pybind/pybind11/pull/5533)\n\nInternal:\n\n- CMake policy limit was set to 4.1.\n [#5944](https://github.com/pybind/pybind11/pull/5944)\n\n- Improved performance of function calls between Python and C++ by switching to the \"vectorcall\" calling protocol.\n [#5948](https://github.com/pybind/pybind11/pull/5948)\n\n- Many C-style casts were replaced with C++-style casts.\n [#5930](https://github.com/pybind/pybind11/pull/5930)\n\n- Added `cast_sources` abstraction to `type_caster_generic`.\n [#5866](https://github.com/pybind/pybind11/pull/5866)\n\n- Improved the performance of from-Python conversions of legacy pybind11 enum objects bound by `py::enum_`.\n [#5860](https://github.com/pybind/pybind11/pull/5860)\n\n- Reduced size overhead by deduplicating functions' readable signatures and type information.\n [#5857](https://github.com/pybind/pybind11/pull/5857)\n\n- Used new Python 3.14 C APIs when available.\n [#5854](https://github.com/pybind/pybind11/pull/5854)\n\n- Improved performance of function dispatch and type casting by porting two-level type info lookup strategy from nanobind.\n [#5842](https://github.com/pybind/pybind11/pull/5842)\n\n- Updated `.gitignore` to exclude `__pycache__/` directories.\n [#5838](https://github.com/pybind/pybind11/pull/5838)\n\n- Changed internals to use `thread_local` instead of `thread_specific_storage` for increased performance.\n [#5834](https://github.com/pybind/pybind11/pull/5834)\n\n- Reduced function call overhead by using thread_local for loader_life_support when possible.\n [#5830](https://github.com/pybind/pybind11/pull/5830)\n\n- Removed heap allocation for the C++ argument array when dispatching functions with 6 or fewer arguments.\n [#5824](https://github.com/pybind/pybind11/pull/5824)\n\n\nDocumentation:\n\n- Fixed docstring for `long double` complex types to use `numpy.clongdouble` instead of the deprecated `numpy.longcomplex` (removed in NumPy 2.0).\n [#5952](https://github.com/pybind/pybind11/pull/5952)\n\n- The \"Supported compilers\" and \"Supported platforms\" sections in the main `README.rst` were replaced with a new \"Supported platforms & compilers\" section that points to the CI test matrix as the living source of truth.\n [#5910](https://github.com/pybind/pybind11/pull/5910)\n\n- Fixed documentation formatting.\n [#5903](https://github.com/pybind/pybind11/pull/5903)\n\n- Updated upgrade notes for `py::native_enum`.\n [#5885](https://github.com/pybind/pybind11/pull/5885)\n\n- Clarified in the docs to what extent bindings are global.\n [#5859](https://github.com/pybind/pybind11/pull/5859)\n\n\nTests:\n\n- Fixed deadlock in a free-threading test by releasing the GIL while waiting on synchronization.\n [#5973](https://github.com/pybind/pybind11/pull/5973)\n\n- Calls to `env.deprecated_call()` were replaced with direct calls to `pytest.deprecated_call()`.\n [#5893](https://github.com/pybind/pybind11/pull/5893)\n\n- Updated pytest configuration to use `log_level` instead of `log_cli_level`.\n [#5890](https://github.com/pybind/pybind11/pull/5890)\n\n\nCI:\n\n- Added CI tests for windows-11-arm with clang/MSVC (currently python 3.13), windows-11-arm with clang/mingw (currently python 3.12).\n [#5932](https://github.com/pybind/pybind11/pull/5932)\n\n- These clang-tidy rules were added: `readability-redundant-casting`, `readability-redundant-inline-specifier`, `readability-redundant-member-init`\n [#5924](https://github.com/pybind/pybind11/pull/5924)\n\n- Replaced deprecated macos-13 runners with macos-15-intel in CI.\n [#5916](https://github.com/pybind/pybind11/pull/5916)\n\n- Restored `runs-on: windows-latest` in CI.\n [#5835](https://github.com/pybind/pybind11/pull/5835)\n\n## Version 3.0.1 (August 22, 2025)\n\nBug fixes:\n\n- Fixed compilation error in `type_caster_enum_type` when casting\n pointer-to-enum types. Added pointer overload to handle dereferencing before\n enum conversion.\n [#5776](https://github.com/pybind/pybind11/pull/5776)\n\n- Implement binary version of `make_index_sequence` to reduce template depth\n requirements for functions with many parameters.\n [#5751](https://github.com/pybind/pybind11/pull/5751)\n\n- Subinterpreter-specific exception handling code was removed to resolve segfaults.\n [#5795](https://github.com/pybind/pybind11/pull/5795)\n\n- Fixed issue that caused ``PYBIND11_MODULE`` code to run again if the module\n was re-imported after being deleted from ``sys.modules``.\n [#5782](https://github.com/pybind/pybind11/pull/5782)\n\n- Prevent concurrent creation of sub-interpreters as a workaround for stdlib\n concurrency issues in Python 3.12.\n [#5779](https://github.com/pybind/pybind11/pull/5779)\n\n- Fixed potential crash when using `cpp_function` objects with sub-interpreters.\n [#5771](https://github.com/pybind/pybind11/pull/5771)\n\n- Fixed non-entrant check in `implicitly_convertible()`.\n [#5777](https://github.com/pybind/pybind11/pull/5777)\n\n- Support C++20 on platforms that have older c++ runtimes.\n [#5761](https://github.com/pybind/pybind11/pull/5761)\n\n- Fix compilation with clang on msys2.\n [#5757](https://github.com/pybind/pybind11/pull/5757)\n\n- Avoid `nullptr` dereference warning with GCC 13.3.0 and python 3.11.13.\n [#5756](https://github.com/pybind/pybind11/pull/5756)\n\n- Fix potential warning about number of threads being too large.\n [#5807](https://github.com/pybind/pybind11/pull/5807)\n\n\n\n\n- Fix gcc 11.4+ warning about serial compilation using CMake.\n [#5791](https://github.com/pybind/pybind11/pull/5791)\n\n\nDocumentation:\n\n- Improve `buffer_info` type checking in numpy docs.\n [#5805](https://github.com/pybind/pybind11/pull/5805)\n\n- Replace `robotpy-build` with `semiwrap` in the binding tool list.\n [#5804](https://github.com/pybind/pybind11/pull/5804)\n\n- Show nogil in most examples.\n [#5770](https://github.com/pybind/pybind11/pull/5770)\n\n- Fix `py::trampoline_self_life_support` visibility in docs.\n [#5766](https://github.com/pybind/pybind11/pull/5766)\n\n\nTests:\n\n- Avoid a spurious warning about `DOWNLOAD_CATCH` being manually specified.\n [#5803](https://github.com/pybind/pybind11/pull/5803)\n\n- Fix an IsolatedConfig test.\n [#5768](https://github.com/pybind/pybind11/pull/5768)\n\n\nCI:\n\n- Add CI testing for Android.\n [#5714](https://github.com/pybind/pybind11/pull/5714)\n\n\nInternal:\n\n- Rename internal variables to avoid the word `slots` (reads better).\n [#5793](https://github.com/pybind/pybind11/pull/5793)\n\n\n## Version 3.0.0 (July 10, 2025)\n\nPybind11 3.0 includes an ABI bump, the first required bump in many years\non Unix (Windows has had required bumps more often). This release contains\nthe smart-holder branch, multi-phase init and subinterpreter support,\n`py::native_enum`, an interface to warnings, typing improvements, and more.\nCMake now defaults to FindPython mode. Please check our upgrade guide for\nmore info on upgrading!\n\nSupport for Python 3.14, 3.14t, GraalPy, and PyPy 3.11 has been added, while\nlegacy support for Python 3.7, PyPy 3.8/3.9, and CMake \\<3.15 has been removed.\nMost deprecated features have been kept for this release, but anything\nproducing a warning in 3.0 may be removed in a future 3.x version. We also now\nhave a deprecation page.\n\nNew Features:\n\n- The `smart_holder` branch has been merged, enabling\n `py::class_`, which handles two-way conversion\n with `std::unique_ptr` and `std::shared_ptr` (simultaneously),\n disowning a Python object being passed to `std::unique_ptr`,\n trampoline objects, and `std::enable_shared_from_this`.\n [#5542](https://github.com/pybind/pybind11/pull/5542)\n\n - Added support for `std::shared_ptr` in `py::init()` when using\n `py::smart_holder`, complementing existing support for\n `std::unique_ptr`.\n [#5731](https://github.com/pybind/pybind11/pull/5731)\n\n - Support const-only smart pointers.\n [#5718](https://github.com/pybind/pybind11/pull/5718)\n\n - Eliminate cross-DSO RTTI reliance from `trampoline_self_life_support` functionality, `smart_holder` deleter detection, and other\n `smart_holder` bookkeeping. Resolves platform-specific issues on macOS related to cross-DSO `dynamic_cast` and `typeid` mismatches.\n [#5728](https://github.com/pybind/pybind11/pull/5728) (replaces [#5700](https://github.com/pybind/pybind11/pull/5700))\n\n- Changed `PYBIND11_MODULE` macro implementation to perform multi-phase\n module initialization (PEP 489) behind the scenes.\n [#5574](https://github.com/pybind/pybind11/pull/5574) and avoid destruction\n [#5688](https://github.com/pybind/pybind11/pull/5688)\n\n- Support for sub-interpreters (both isolated (with separate GILs) and\n legacy (with a global GIL). Add the\n `py::multiple_interpreters::per_interpreter_gil()` tag (or,\n `py::multiple_interpreters::shared_gil()` for legacy interpreter\n support) to `PYBIND11_MODULE` calls (as the third parameter) to\n indicate that a module supports running with sub-interpreters.\n [#5564](https://github.com/pybind/pybind11/pull/5564)\n\n - Rename macro `PYBIND11_SUBINTERPRETER_SUPPORT` -> `PYBIND11_HAS_SUBINTERPRETER_SUPPORT` to meet naming convention.\n [#5682](https://github.com/pybind/pybind11/pull/5682)\n\n - Allow subinterpreter support to be disabled if defined to 0. This is mostly an emergency workaround, and is not exposed in CMake.\n [#5708](https://github.com/pybind/pybind11/pull/5708) and [#5710](https://github.com/pybind/pybind11/pull/5710)\n\n - Modify internals pointer-to-pointer implementation to not use `thread_local` (better iOS support).\n [#5709](https://github.com/pybind/pybind11/pull/5709)\n\n - Support implementations without subinterpreter support.\n [#5732](https://github.com/pybind/pybind11/pull/5732)\n\n- Changed `PYBIND11_EMBEDDED_MODULE` macro implementation to perform\n multi-phase module initialization (PEP 489) behind the scenes and to\n support `py::mod_gil_not_used()`,\n `py::multiple_interpreters::per_interpreter_gil()` and\n `py::multiple_interpreters::shared_gil()`.\n [#5665](https://github.com/pybind/pybind11/pull/5665) and consolidate code\n [#5670](https://github.com/pybind/pybind11/pull/5670).\n\n- Added API in `pybind11/subinterpreter.h` for embedding sub-interpreters (requires Python 3.12+).\n [#5666](https://github.com/pybind/pybind11/pull/5666)\n\n- `py::native_enum` was added, for conversions between Python's native\n (stdlib) enum types and C++ enums.\n [#5555](https://github.com/pybind/pybind11/pull/5555)\n\n - Add class doc string to `py::native_enum`.\n [#5617](https://github.com/pybind/pybind11/pull/5617).\n\n - Fix signature for functions with a `native_enum` in the signature.\n [#5619](https://github.com/pybind/pybind11/pull/5619)\n\n- Support `py::numpy_scalar<>` / `py::make_scalar()` for NumPy types.\n [#5726](https://github.com/pybind/pybind11/pull/5726)\n\n- A `py::release_gil_before_calling_cpp_dtor` option (for `py::class_`)\n was added to resolve the long-standing issue \\#1446.\n [#5522](https://github.com/pybind/pybind11/pull/5522)\n\n- Add `dtype::normalized_num` and `dtype::num_of`.\n [#5429](https://github.com/pybind/pybind11/pull/5429)\n\n- Add support for `array_t` and `array_t`.\n [#5427](https://github.com/pybind/pybind11/pull/5427)\n\n- Added `py::warnings` namespace with `py::warnings::warn` and\n `py::warnings::new_warning_type` that provides the interface for\n Python warnings.\n [#5291](https://github.com/pybind/pybind11/pull/5291)\n\n- `stl.h` `list|set|map_caster` were made more user friendly: it is no\n longer necessary to explicitly convert Python iterables to `tuple()`,\n `set()`, or `map()` in many common situations.\n [#4686](https://github.com/pybind/pybind11/pull/4686)\n\n- The `array_caster` in pybind11/stl.h was enhanced to support value\n types that are not default-constructible.\n [#5305](https://github.com/pybind/pybind11/pull/5305)\n\n- `pybind11/conduit/pybind11_platform_abi_id.h` was factored out, to\n maximize reusability of `PYBIND11_PLATFORM_ABI_ID` (for other\n Python/C++ binding systems). Separately, a note was added to explain\n that the conduit feature only covers from-Python-to-C++ conversions.\n [#5375](https://github.com/pybind/pybind11/pull/5375) \\|\n [#5740](https://github.com/pybind/pybind11/pull/5740)\n\n- Added support for finding pybind11 using pkgconf distributed on pypi.\n [#5552](https://github.com/pybind/pybind11/pull/5552)\n\n- Support `--extension-suffix` on the pybind11 command.\n [#5360](https://github.com/pybind/pybind11/pull/5360)\n\n- Add semi-public API: `pybind11::detail::is_holder_constructed` and\n update example for `pybind11::custom_type_setup` in documentation.\n [#5669](https://github.com/pybind/pybind11/pull/5669)\n\n- Added `py::scoped_critical_section` to support free-threaded mode.\n [#5684](https://github.com/pybind/pybind11/pull/5684) \\|\n [#5706](https://github.com/pybind/pybind11/pull/5706)\n\nNew Features / fixes (typing):\n\n- Added option for different arg/return type hints to `type_caster`.\n Updated `stl/filesystem` to use correct arg/return type hints. Updated\n `pybind11::typing` to use correct arg/return type hints for nested\n types. [#5450](https://github.com/pybind/pybind11/pull/5450)\n- Updated type hint for `py::capsule` to `type.CapsuleType`.\n [#5567](https://github.com/pybind/pybind11/pull/5567)\n- Adds support for `typing.SupportsInt` and `typing.SupportsFloat`.\n Update `Final` to be narrower type hint. Make `std::function` match\n `Callable` type. Fix `io_name` bug in `attr_with_type_hint`.\n [#5540](https://github.com/pybind/pybind11/pull/5540)\n- Rework of arg/return type hints to support `.noconvert()`.\n [#5486](https://github.com/pybind/pybind11/pull/5486)\n- Add `attr_with_type` for declaring attribute types and `Final`,\n `ClassVar` type annotations.\n [#5460](https://github.com/pybind/pybind11/pull/5460)\n- Allow annotate methods with `py::pos_only` when only have the `self`\n argument. Make arguments for auto-generated dunder methods\n positional-only.\n [#5403](https://github.com/pybind/pybind11/pull/5403)\n- Added `py::Args` and `py::KWArgs` to enable custom type hinting of\n `*args` and `**kwargs` (see PEP 484).\n [#5357](https://github.com/pybind/pybind11/pull/5357)\n- Switched to `numpy.typing.NDArray` and `numpy.typing.ArrayLike`.\n [#5212](https://github.com/pybind/pybind11/pull/5212)\n- Use `numpy.object_` instead of `object`.\n [#5571](https://github.com/pybind/pybind11/pull/5571)\n- Fix module type hint.\n [#5469](https://github.com/pybind/pybind11/pull/5469)\n- Fix Buffer type hint.\n [#5662](https://github.com/pybind/pybind11/pull/5662)\n- Added support for `collections.abc` in type hints and convertible\n checks of STL casters and `py::buffer`.\n [#5566](https://github.com/pybind/pybind11/pull/5566)\n- Fix `typing` and `collections.abc` type hint ambiguity.\n [#5663](https://github.com/pybind/pybind11/pull/5663)\n- Add `typing_extensions` alternatives for all types that need them.\n [#5693](https://github.com/pybind/pybind11/pull/5693)\n\nRemovals:\n\n- Remove support for pybind11 v2 internals versions (4, 5, 6). (The\n internals version number has been bumped for pybind11 v3.)\n [#5512](https://github.com/pybind/pybind11/pull/5512) \\|\n [#5530](https://github.com/pybind/pybind11/pull/5530)\n- Remove `make_simple_namespace` (added in 2.8.0, deprecated in 2.8.1).\n [#5597](https://github.com/pybind/pybind11/pull/5597)\n- Legacy-mode option `PYBIND11_NUMPY_1_ONLY` has been removed.\n [#5595](https://github.com/pybind/pybind11/pull/5595)\n- Add a deprecation warning to `.get_type` (deprecated in pybind11 2.6\n in 2020). [#5596](https://github.com/pybind/pybind11/pull/5596)\n\nBug fixes:\n\n- Set `__file__` on submodules.\n [#5584](https://github.com/pybind/pybind11/pull/5584). Except on\n embedded modules.\n [#5650](https://github.com/pybind/pybind11/pull/5650)\n- pybind11-bound functions are now pickleable.\n [#5580](https://github.com/pybind/pybind11/pull/5580)\n- Fix bug in `attr_with_type_hint` to allow objects to be in\n `attr_with_type_hint`.\n [#5576](https://github.com/pybind/pybind11/pull/5576)\n- A `-Wmaybe-uninitialized` warning suppression was added in\n `pybind11/eigen/matrix.h`.\n [#5516](https://github.com/pybind/pybind11/pull/5516)\n- `PYBIND11_WARNING_POP` was incorrectly defined as\n `PYBIND11_PRAGMA(clang diagnostic push)`.\n [#5448](https://github.com/pybind/pybind11/pull/5448)\n- `PYBIND11_PLATFORM_ABI_ID` (which is used in composing\n `PYBIND11_INTERNALS_ID`) was modernized to reflect actual ABI\n compatibility more accurately.\n [#4953](https://github.com/pybind/pybind11/pull/4953) \\|\n [#5439](https://github.com/pybind/pybind11/pull/5439)\n- Fix buffer protocol implementation.\n [#5407](https://github.com/pybind/pybind11/pull/5407)\n- Fix iterator increment operator does not skip first item.\n [#5400](https://github.com/pybind/pybind11/pull/5400)\n- When getting or deleting an element in a container bound by\n `bind_map`, print the key in `KeyError` if it does not exist.\n [#5397](https://github.com/pybind/pybind11/pull/5397)\n- `pybind11::builtin_exception` is now explicitly exported when linked\n to libc++. [#5390](https://github.com/pybind/pybind11/pull/5390)\n- Allow subclasses of `py::args` and `py::kwargs`.\n [#5381](https://github.com/pybind/pybind11/pull/5381)\n- Disable false-positive GCC 12 Bound Check warning.\n [#5355](https://github.com/pybind/pybind11/pull/5355)\n- Update the dict when restoring pickles, instead of assigning a\n replacement dict.\n [#5658](https://github.com/pybind/pybind11/pull/5658)\n- Properly define `_DEBUG` macro to `1` instead of defining it without\n value. [#5639](https://github.com/pybind/pybind11/pull/5639)\n- Fix a missing time cast causing a compile error for newer ICC.\n [#5621](https://github.com/pybind/pybind11/pull/5621)\n- Change the behavior of the default constructor of `py::slice` to be\n equivalent to `::` in Python.\n [#5620](https://github.com/pybind/pybind11/pull/5620)\n\nBug fixes and features (CMake):\n\n- Enable FindPython mode by default, with a `COMPAT` mode that\n sets some of the old variables to ease transition.\n [#5553](https://github.com/pybind/pybind11/pull/5553)\n- Add an author warning that auto-calculated `PYTHON_MODULE_EXTENSION`\n may not respect `SETUPTOOLS_EXT_SUFFIX` during cross-compilation.\n [#5495](https://github.com/pybind/pybind11/pull/5495)\n- Don't strip with `CMAKE_BUILD_TYPE` None.\n [#5392](https://github.com/pybind/pybind11/pull/5392)\n- Fix an issue with `NO_EXTRAS` adding `pybind11::windows_extras`\n anyway. [#5378](https://github.com/pybind/pybind11/pull/5378)\n- Fix issue with NEW/OLD message showing up.\n [#5656](https://github.com/pybind/pybind11/pull/5656)\n- Use CMake's warnings as errors if available (CMake 3.24+).\n [#5612](https://github.com/pybind/pybind11/pull/5612)\n- Add support for running pybind11's tests via presets in CMake 3.25+.\n [#5655](https://github.com/pybind/pybind11/pull/5655) and support `--fresh`.\n [#5668](https://github.com/pybind/pybind11/pull/5668)\n- Experimental CMake support for Android.\n [#5733](https://github.com/pybind/pybind11/pull/5733)\n- Presets now generate `compile_commands.json`.\n [#5685](https://github.com/pybind/pybind11/pull/5685)\n\nBug fixes (free-threading):\n\n- Fix data race in free threaded CPython when accessing a shared static\n variable. [#5494](https://github.com/pybind/pybind11/pull/5494)\n- A free-threading data race in `all_type_info()` was fixed.\n [#5419](https://github.com/pybind/pybind11/pull/5419)\n- Added exception translator specific mutex used with\n `try_translate_exceptions` in the free-threaded build for internal\n locking. [#5362](https://github.com/pybind/pybind11/pull/5362)\n\nInternals:\n\n- Consolidated all `PYBIND11_HAS_...` feature macros into\n `pybind11/detail/common.h` to streamline backward compatibility checks and\n simplify internal refactoring. This change ensures consistent macro\n availability regardless of header inclusion order.\n [#5647](https://github.com/pybind/pybind11/pull/5647)\n\n- `pybind11/gil_simple.h` was factored out from `pybind11/gil.h`, so\n that it can easily be reused.\n [#5614](https://github.com/pybind/pybind11/pull/5614)\n\n- Use CPython macros to construct `PYBIND11_VERSION_HEX`.\n [#5683](https://github.com/pybind/pybind11/pull/5683)\n\nDocumentation:\n\n- Improved `reference_internal` policy documentation.\n [#5528](https://github.com/pybind/pybind11/pull/5528)\n\n- A new \"Double locking, deadlocking, GIL\" document was added.\n [#5394](https://github.com/pybind/pybind11/pull/5394)\n\n- Add documenting for free-threading and subinterpreters.\n [#5659](https://github.com/pybind/pybind11/pull/5659)\n\nTests:\n\n- Download the final Catch2 2.x release if Catch download is requested.\n [#5568](https://github.com/pybind/pybind11/pull/5568)\n\n- Explicitly used `signed char` for two numpy dtype tests. As seen when\n compiling using `clang` on Linux with the `-funsigned-char` flag.\n [#5545](https://github.com/pybind/pybind11/pull/5545)\n\n- CI testing now includes\n `-Wwrite-strings -Wunreachable-code -Wpointer-arith -Wredundant-decls`\n in some jobs.\n [#5523](https://github.com/pybind/pybind11/pull/5523)\n\n- Add nightly wheels to scientific-python's nightly wheelhouse.\n [#5675](https://github.com/pybind/pybind11/pull/5675)\n\n- Expect free-threaded warning when loading a non-free-threaded module.\n [#5680](https://github.com/pybind/pybind11/pull/5680)\n\n- Run pytest under Python devmode.\n [#5715](https://github.com/pybind/pybind11/pull/5715)\n\nNew and removed platforms:\n\n- Support Python 3.14 (beta 1+).\n [#5646](https://github.com/pybind/pybind11/pull/5646)\n\n- Added support for GraalPy Python implementation\n ().\n [#5380](https://github.com/pybind/pybind11/pull/5380)\n\n- Support and test iOS in CI.\n [#5705](https://github.com/pybind/pybind11/pull/5705)\n\n- Support for PyPy 3.11 added.\n [#5508](https://github.com/pybind/pybind11/pull/5508)\n And test in ci.\n [#5534](https://github.com/pybind/pybind11/pull/5534)\n\n- Support for PyPy 3.8 and 3.9 was dropped.\n [#5578](https://github.com/pybind/pybind11/pull/5578)\n\n- Support for Python 3.7 was removed. (Official end-of-life:\n 2023-06-27).\n [#5191](https://github.com/pybind/pybind11/pull/5191)\n\n- Support for CMake older than 3.15 removed. CMake 3.15-4.0 supported.\n [#5304](https://github.com/pybind/pybind11/pull/5304) and fix regression [#5691](https://github.com/pybind/pybind11/pull/5691).\n\n- Use scikit-build-core for the build backend for the PyPI `pybind11`.\n The CMake generation has been moved to the sdist-\\>wheel step.\n `PYBIND11_GLOBAL_SDIST` has been removed.\n [#5598](https://github.com/pybind/pybind11/pull/5598) and updated\n docs/ci. [#5676](https://github.com/pybind/pybind11/pull/5676)\n\n- clang 20 tested and used for clang-tidy.\n [#5692](https://github.com/pybind/pybind11/pull/5692)\n\n- Drop testing on MSVC 2019 (as it is being removed from GitHub).\n [#5712](https://github.com/pybind/pybind11/pull/5712)\n\n- Support Windows C++20 and Linux C++23 in tests.\n [#5707](https://github.com/pybind/pybind11/pull/5707)\n\n## Version 2.13.6 (September 13, 2024)\n\nNew Features:\n\n- A new `self._pybind11_conduit_v1_()` method is automatically added to\n all `py::class_`-wrapped types, to enable type-safe interoperability\n between different independent Python/C++ bindings systems, including\n pybind11 versions with different `PYBIND11_INTERNALS_VERSION`'s.\n Supported on pybind11 2.11.2, 2.12.1, and 2.13.6+.\n [#5296](https://github.com/pybind/pybind11/pull/5296)\n\nBug fixes:\n\n- Using `__cpp_nontype_template_args` instead of\n `__cpp_nontype_template_parameter_class`.\n [#5330](https://github.com/pybind/pybind11/pull/5330)\n- Properly translate C++ exception to Python exception when creating\n Python buffer from wrapped object.\n [#5324](https://github.com/pybind/pybind11/pull/5324)\n\nDocumentation:\n\n- Adds an answer (FAQ) for \"What is a highly conclusive and simple way\n to find memory leaks?\".\n [#5340](https://github.com/pybind/pybind11/pull/5340)\n\n## Version 2.13.5 (August 22, 2024)\n\nBug fixes:\n\n- Fix includes when using Windows long paths (`\\\\?\\` prefix).\n [#5321](https://github.com/pybind/pybind11/pull/5321)\n- Support `-Wpedantic` in C++20 mode.\n [#5322](https://github.com/pybind/pybind11/pull/5322)\n- Fix and test `` support for `py::tuple` and `py::list`.\n [#5314](https://github.com/pybind/pybind11/pull/5314)\n\n## Version 2.13.4 (August 14, 2024)\n\nBug fixes:\n\n- Fix paths with spaces, including on Windows. (Replaces regression from\n [#5302](https://github.com/pybind/pybind11/pull/5302))\n [#4874](https://github.com/pybind/pybind11/pull/4874)\n\nDocumentation:\n\n- Remove repetitive words.\n [#5308](https://github.com/pybind/pybind11/pull/5308)\n\n## Version 2.13.3 (August 13, 2024)\n\nBug fixes:\n\n- Quote paths from pybind11-config\n [#5302](https://github.com/pybind/pybind11/pull/5302)\n- Fix typo in Emscripten support when in config mode (CMake)\n [#5301](https://github.com/pybind/pybind11/pull/5301)\n\n## Version 2.13.2 (August 13, 2024)\n\nNew Features:\n\n- A `pybind11::detail::type_caster_std_function_specializations` feature\n was added, to support specializations for `std::function`'s with\n return types that require custom to-Python conversion behavior (to\n primary use case is to catch and convert exceptions).\n [#4597](https://github.com/pybind/pybind11/pull/4597)\n\nChanges:\n\n- Use `PyMutex` instead of `std::mutex` for internal locking in the\n free-threaded build.\n [#5219](https://github.com/pybind/pybind11/pull/5219)\n- Add a special type annotation for C++ empty tuple.\n [#5214](https://github.com/pybind/pybind11/pull/5214)\n- When compiling for WebAssembly, add the required exception flags\n (CMake 3.13+). [#5298](https://github.com/pybind/pybind11/pull/5298)\n\nBug fixes:\n\n- Make `gil_safe_call_once_and_store` thread-safe in free-threaded\n CPython. [#5246](https://github.com/pybind/pybind11/pull/5246)\n- A missing `#include ` in pybind11/typing.h was added to fix\n build errors (in case user code does not already depend on that\n include). [#5208](https://github.com/pybind/pybind11/pull/5208)\n- Fix regression introduced in \\#5201 for GCC\\<10.3 in C++20 mode.\n [#5205](https://github.com/pybind/pybind11/pull/5205)\n\n\n\n- Remove extra = when assigning flto value in the case for Clang in\n CMake. [#5207](https://github.com/pybind/pybind11/pull/5207)\n\nTests:\n\n- Adding WASM testing to our CI (Pyodide / Emscripten via\n scikit-build-core).\n [#4745](https://github.com/pybind/pybind11/pull/4745)\n- clang-tidy (in GitHub Actions) was updated from clang 15 to clang 18.\n [#5272](https://github.com/pybind/pybind11/pull/5272)\n\n## Version 2.13.1 (June 26, 2024)\n\nNew Features:\n\n- Add support for `Typing.Callable[..., T]`.\n [#5202](https://github.com/pybind/pybind11/pull/5202)\n\nBug fixes:\n\n- Avoid aligned allocation in free-threaded build in order to support\n macOS versions before 10.14.\n [#5200](https://github.com/pybind/pybind11/pull/5200)\n\n## Version 2.13.0 (June 25, 2024)\n\nNew Features:\n\n- Support free-threaded CPython (3.13t). Add `py::mod_gil_not_used()`\n tag to indicate if a module supports running with the GIL disabled.\n [#5148](https://github.com/pybind/pybind11/pull/5148)\n- Support for Python 3.6 was removed. (Official end-of-life:\n 2021-12-23). [#5177](https://github.com/pybind/pybind11/pull/5177)\n- `py::list` gained a `.clear()` method.\n [#5153](https://github.com/pybind/pybind11/pull/5153)\n\n\n\n- Support for `Union`, `Optional`, `type[T]`, `typing.TypeGuard`,\n `typing.TypeIs`, `typing.Never`, `typing.NoReturn` and\n `typing.Literal` was added to `pybind11/typing.h`.\n [#5166](https://github.com/pybind/pybind11/pull/5166)\n [#5165](https://github.com/pybind/pybind11/pull/5165)\n [#5194](https://github.com/pybind/pybind11/pull/5194)\n [#5193](https://github.com/pybind/pybind11/pull/5193)\n [#5192](https://github.com/pybind/pybind11/pull/5192)\n\n\n\n- In CMake, if `PYBIND11_USE_CROSSCOMPILING` is enabled, then\n `CMAKE_CROSSCOMPILING` will be respected and will keep pybind11 from\n accessing the interpreter during configuration. Several CMake\n variables will be required in this case, but can be deduced from the\n environment variable `SETUPTOOLS_EXT_SUFFIX`. The default (currently\n `OFF`) may be changed in the future.\n [#5083](https://github.com/pybind/pybind11/pull/5083)\n\nBug fixes:\n\n- A refcount bug (leading to heap-use-after-free) involving trampoline\n functions with `PyObject *` return type was fixed.\n [#5156](https://github.com/pybind/pybind11/pull/5156)\n- Return `py::ssize_t` from `.ref_count()` instead of `int`.\n [#5139](https://github.com/pybind/pybind11/pull/5139)\n- A subtle bug involving C++ types with unusual `operator&` overrides\n was fixed. [#5189](https://github.com/pybind/pybind11/pull/5189)\n- Support Python 3.13 with minor fix, add to CI.\n [#5127](https://github.com/pybind/pybind11/pull/5127)\n\n\n\n- Fix mistake affecting old cmake and old boost.\n [#5149](https://github.com/pybind/pybind11/pull/5149)\n\nDocumentation:\n\n- Build docs updated to feature scikit-build-core and meson-python, and\n updated setuptools instructions.\n [#5168](https://github.com/pybind/pybind11/pull/5168)\n\nTests:\n\n- Avoid immortal objects in tests.\n [#5150](https://github.com/pybind/pybind11/pull/5150)\n\nCI:\n\n- Compile against Python 3.13t in CI.\n- Use `macos-13` (Intel) for CI jobs for now (will drop Python 3.7\n soon). [#5109](https://github.com/pybind/pybind11/pull/5109)\n- Releases now have artifact attestations, visible at\n .\n [#5196](https://github.com/pybind/pybind11/pull/5196)\n\nOther:\n\n- Some cleanup in preparation for 3.13 support.\n [#5137](https://github.com/pybind/pybind11/pull/5137)\n- Avoid a warning by ensuring an iterator end check is included in\n release mode. [#5129](https://github.com/pybind/pybind11/pull/5129)\n- Bump max cmake to 3.29.\n [#5075](https://github.com/pybind/pybind11/pull/5075)\n- Update docs and noxfile.\n [#5071](https://github.com/pybind/pybind11/pull/5071)\n\n## Version 2.12.1 (September 13, 2024)\n\nNew Features:\n\n- A new `self._pybind11_conduit_v1_()` method is automatically added to\n all `py::class_`-wrapped types, to enable type-safe interoperability\n between different independent Python/C++ bindings systems, including\n pybind11 versions with different `PYBIND11_INTERNALS_VERSION`'s.\n Supported on pybind11 2.11.2, 2.12.1, and 2.13.6+.\n [#5296](https://github.com/pybind/pybind11/pull/5296)\n\n## Version 2.12.0 (March 27, 2024)\n\nNew Features:\n\n- `pybind11` now supports compiling for [NumPy\n 2](https://numpy.org/devdocs/numpy_2_0_migration_guide.html). Most\n code shouldn't change (see `upgrade-guide-2.12` for details). However,\n if you experience issues you can define `PYBIND11_NUMPY_1_ONLY` to\n disable the new support for now, but this will be removed in the\n future. [#5050](https://github.com/pybind/pybind11/pull/5050)\n- `pybind11/gil_safe_call_once.h` was added (it needs to be included\n explicitly). The primary use case is GIL-safe initialization of C++\n `static` variables.\n [#4877](https://github.com/pybind/pybind11/pull/4877)\n- Support move-only iterators in `py::make_iterator`,\n `py::make_key_iterator`, `py::make_value_iterator`.\n [#4834](https://github.com/pybind/pybind11/pull/4834)\n- Two simple `py::set_error()` functions were added and the\n documentation was updated accordingly. In particular,\n `py::exception<>::operator()` was deprecated (use one of the new\n functions instead). The documentation for `py::exception<>` was\n further updated to not suggest code that may result in undefined\n behavior. [#4772](https://github.com/pybind/pybind11/pull/4772)\n\nBug fixes:\n\n- Removes potential for Undefined Behavior during process teardown.\n [#4897](https://github.com/pybind/pybind11/pull/4897)\n- Improve compatibility with the nvcc compiler (especially CUDA\n 12.1/12.2). [#4893](https://github.com/pybind/pybind11/pull/4893)\n- `pybind11/numpy.h` now imports NumPy's `multiarray` and `_internal`\n submodules with paths depending on the installed version of NumPy (for\n compatibility with NumPy 2).\n [#4857](https://github.com/pybind/pybind11/pull/4857)\n- Builtins collections names in docstrings are now consistently rendered\n in lowercase (list, set, dict, tuple), in accordance with PEP 585.\n [#4833](https://github.com/pybind/pybind11/pull/4833)\n- Added `py::typing::Iterator`, `py::typing::Iterable`.\n [#4832](https://github.com/pybind/pybind11/pull/4832)\n- Render `py::function` as `Callable` in docstring.\n [#4829](https://github.com/pybind/pybind11/pull/4829)\n- Also bump `PYBIND11_INTERNALS_VERSION` for MSVC, which unlocks two new\n features without creating additional incompatibilities.\n [#4819](https://github.com/pybind/pybind11/pull/4819)\n- Guard against crashes/corruptions caused by modules built with\n different MSVC versions.\n [#4779](https://github.com/pybind/pybind11/pull/4779)\n- A long-standing bug in the handling of Python multiple inheritance was\n fixed. See PR \\#4762 for the rather complex details.\n [#4762](https://github.com/pybind/pybind11/pull/4762)\n- Fix `bind_map` with `using` declarations.\n [#4952](https://github.com/pybind/pybind11/pull/4952)\n- Qualify `py::detail::concat` usage to avoid ADL selecting one from\n somewhere else, such as modernjson's concat.\n [#4955](https://github.com/pybind/pybind11/pull/4955)\n- Use new PyCode API on Python 3.12+.\n [#4916](https://github.com/pybind/pybind11/pull/4916)\n- Minor cleanup from warnings reported by Clazy.\n [#4988](https://github.com/pybind/pybind11/pull/4988)\n- Remove typing and duplicate `class_` for\n `KeysView`/`ValuesView`/`ItemsView`.\n [#4985](https://github.com/pybind/pybind11/pull/4985)\n- Use `PyObject_VisitManagedDict()` and `PyObject_ClearManagedDict()` on\n Python 3.13 and newer.\n [#4973](https://github.com/pybind/pybind11/pull/4973)\n- Update `make_static_property_type()` to make it compatible with Python\n 3.13. [#4971](https://github.com/pybind/pybind11/pull/4971)\n\n\n\n- Render typed iterators for `make_iterator`, `make_key_iterator`,\n `make_value_iterator`.\n [#4876](https://github.com/pybind/pybind11/pull/4876)\n- Add several missing type name specializations.\n [#5073](https://github.com/pybind/pybind11/pull/5073)\n- Change docstring render for `py::buffer`, `py::sequence` and\n `py::handle` (to `Buffer`, `Sequence`, `Any`).\n [#4831](https://github.com/pybind/pybind11/pull/4831)\n- Fixed `base_enum.__str__` docstring.\n [#4827](https://github.com/pybind/pybind11/pull/4827)\n- Enforce single line docstring signatures.\n [#4735](https://github.com/pybind/pybind11/pull/4735)\n- Special 'typed' wrappers now available in `typing.h` to annotate\n tuple, dict, list, set, and function.\n [#4259](https://github.com/pybind/pybind11/pull/4259)\n- Create `handle_type_name` specialization to type-hint variable length\n tuples. [#5051](https://github.com/pybind/pybind11/pull/5051)\n\n\n\n- Setting `PYBIND11_FINDPYTHON` to OFF will force the old FindPythonLibs\n mechanism to be used.\n [#5042](https://github.com/pybind/pybind11/pull/5042)\n- Skip empty `PYBIND11_PYTHON_EXECUTABLE_LAST` for the first cmake run.\n [#4856](https://github.com/pybind/pybind11/pull/4856)\n- Fix FindPython mode exports & avoid `pkg_resources` if\n `importlib.metadata` available.\n [#4941](https://github.com/pybind/pybind11/pull/4941)\n- `Python_ADDITIONAL_VERSIONS` (classic search) now includes 3.12.\n [#4909](https://github.com/pybind/pybind11/pull/4909)\n- `pybind11.pc` is now relocatable by default as long as install\n destinations are not absolute paths.\n [#4830](https://github.com/pybind/pybind11/pull/4830)\n- Correctly detect CMake FindPython removal when used as a subdirectory.\n [#4806](https://github.com/pybind/pybind11/pull/4806)\n- Don't require the libs component on CMake 3.18+ when using\n PYBIND11_FINDPYTHON (fixes manylinux builds).\n [#4805](https://github.com/pybind/pybind11/pull/4805)\n- `pybind11_strip` is no longer automatically applied when\n `CMAKE_BUILD_TYPE` is unset.\n [#4780](https://github.com/pybind/pybind11/pull/4780)\n- Support `DEBUG_POSFIX` correctly for debug builds.\n [#4761](https://github.com/pybind/pybind11/pull/4761)\n- Hardcode lto/thin lto for Emscripten cross-compiles.\n [#4642](https://github.com/pybind/pybind11/pull/4642)\n- Upgrade maximum supported CMake version to 3.27 to fix CMP0148\n warnings. [#4786](https://github.com/pybind/pybind11/pull/4786)\n\nDocumentation:\n\n- Small fix to grammar in `functions.rst`.\n [#4791](https://github.com/pybind/pybind11/pull/4791)\n- Remove upper bound in example pyproject.toml for setuptools.\n [#4774](https://github.com/pybind/pybind11/pull/4774)\n\nCI:\n\n- CI: Update NVHPC to 23.5 and Ubuntu 20.04.\n [#4764](https://github.com/pybind/pybind11/pull/4764)\n- Test on PyPy 3.10.\n [#4714](https://github.com/pybind/pybind11/pull/4714)\n\nOther:\n\n- Use Ruff formatter instead of Black.\n [#4912](https://github.com/pybind/pybind11/pull/4912)\n- An `assert()` was added to help Coverty avoid generating a false\n positive. [#4817](https://github.com/pybind/pybind11/pull/4817)\n\n## Version 2.11.2 (September 13, 2024)\n\nNew Features:\n\n- A new `self._pybind11_conduit_v1_()` method is automatically added to\n all `py::class_`-wrapped types, to enable type-safe interoperability\n between different independent Python/C++ bindings systems, including\n pybind11 versions with different `PYBIND11_INTERNALS_VERSION`'s.\n Supported on pybind11 2.11.2, 2.12.1, and 2.13.6+.\n [#5296](https://github.com/pybind/pybind11/pull/5296)\n\n## Version 2.11.1 (July 17, 2023)\n\nChanges:\n\n- `PYBIND11_NO_ASSERT_GIL_HELD_INCREF_DECREF` is now provided as an\n option for disabling the default-on `PyGILState_Check()`'s in\n `pybind11::handle`'s `inc_ref()` & `dec_ref()`.\n [#4753](https://github.com/pybind/pybind11/pull/4753)\n- `PYBIND11_ASSERT_GIL_HELD_INCREF_DECREF` was disabled for PyPy in\n general (not just PyPy Windows).\n [#4751](https://github.com/pybind/pybind11/pull/4751)\n\n## Version 2.11.0 (July 14, 2023)\n\nNew features:\n\n- The newly added `pybind11::detail::is_move_constructible` trait can be\n specialized for cases in which `std::is_move_constructible` does not\n work as needed. This is very similar to the long-established\n `pybind11::detail::is_copy_constructible`.\n [#4631](https://github.com/pybind/pybind11/pull/4631)\n- Introduce `recursive_container_traits`.\n [#4623](https://github.com/pybind/pybind11/pull/4623)\n- `pybind11/type_caster_pyobject_ptr.h` was added to support automatic\n wrapping of APIs that make use of `PyObject *`. This header needs to\n included explicitly (i.e. it is not included implicitly with\n `pybind/pybind11.h`).\n [#4601](https://github.com/pybind/pybind11/pull/4601)\n- `format_descriptor<>` & `npy_format_descriptor<>` `PyObject *`\n specializations were added. The latter enables\n `py::array_t` to/from-python conversions.\n [#4674](https://github.com/pybind/pybind11/pull/4674)\n- `buffer_info` gained an `item_type_is_equivalent_to()` member\n function. [#4674](https://github.com/pybind/pybind11/pull/4674)\n- The `capsule` API gained a user-friendly constructor\n (`py::capsule(ptr, \"name\", dtor)`).\n [#4720](https://github.com/pybind/pybind11/pull/4720)\n\nChanges:\n\n- `PyGILState_Check()`'s in `pybind11::handle`'s `inc_ref()` &\n `dec_ref()` are now enabled by default again.\n [#4246](https://github.com/pybind/pybind11/pull/4246)\n- `py::initialize_interpreter()` using `PyConfig_InitPythonConfig()`\n instead of `PyConfig_InitIsolatedConfig()`, to obtain complete\n `sys.path`. [#4473](https://github.com/pybind/pybind11/pull/4473)\n- Cast errors now always include Python type information, even if\n `PYBIND11_DETAILED_ERROR_MESSAGES` is not defined. This increases\n binary sizes slightly (~1.5%) but the error messages are much more\n informative. [#4463](https://github.com/pybind/pybind11/pull/4463)\n- The docstring generation for the `std::array`-list caster was fixed.\n Previously, signatures included the size of the list in a\n non-standard, non-spec compliant way. The new format conforms to\n PEP 593. **Tooling for processing the docstrings may need to be\n updated accordingly.**\n [#4679](https://github.com/pybind/pybind11/pull/4679)\n- Setter return values (which are inaccessible for all practical\n purposes) are no longer converted to Python (only to be discarded).\n [#4621](https://github.com/pybind/pybind11/pull/4621)\n- Allow lambda specified to function definition to be `noexcept(true)`\n in C++17. [#4593](https://github.com/pybind/pybind11/pull/4593)\n- Get rid of recursive template instantiations for concatenating type\n signatures on C++17 and higher.\n [#4587](https://github.com/pybind/pybind11/pull/4587)\n- Compatibility with Python 3.12 (beta). Note that the minimum pybind11\n ABI version for Python 3.12 is version 5. (The default ABI version for\n Python versions up to and including 3.11 is still version 4.).\n [#4570](https://github.com/pybind/pybind11/pull/4570)\n- With `PYBIND11_INTERNALS_VERSION 5` (default for Python 3.12+), MSVC\n builds use `std::hash` and\n `std::equal_to` instead of string-based type\n comparisons. This resolves issues when binding types defined in the\n unnamed namespace.\n [#4319](https://github.com/pybind/pybind11/pull/4319)\n- Python exception `__notes__` (introduced with Python 3.11) are now\n added to the `error_already_set::what()` output.\n [#4678](https://github.com/pybind/pybind11/pull/4678)\n\nBuild system improvements:\n\n- CMake 3.27 support was added, CMake 3.4 support was dropped.\n FindPython will be used if `FindPythonInterp` is not present.\n [#4719](https://github.com/pybind/pybind11/pull/4719)\n- Update clang-tidy to 15 in CI.\n [#4387](https://github.com/pybind/pybind11/pull/4387)\n- Moved the linting framework over to Ruff.\n [#4483](https://github.com/pybind/pybind11/pull/4483)\n- Skip `lto` checks and target generation when\n `CMAKE_INTERPROCEDURAL_OPTIMIZATION` is defined.\n [#4643](https://github.com/pybind/pybind11/pull/4643)\n- No longer inject `-stdlib=libc++`, not needed for modern Pythons\n (macOS 10.9+). [#4639](https://github.com/pybind/pybind11/pull/4639)\n- PyPy 3.10 support was added, PyPy 3.7 support was dropped.\n [#4728](https://github.com/pybind/pybind11/pull/4728)\n- Testing with Python 3.12 beta releases was added.\n [#4713](https://github.com/pybind/pybind11/pull/4713)\n\n## Version 2.10.4 (Mar 16, 2023)\n\nChanges:\n\n- `python3 -m pybind11` gained a `--version` option (prints the version\n and exits). [#4526](https://github.com/pybind/pybind11/pull/4526)\n\nBug Fixes:\n\n- Fix a warning when pydebug is enabled on Python 3.11.\n [#4461](https://github.com/pybind/pybind11/pull/4461)\n- Ensure `gil_scoped_release` RAII is non-copyable.\n [#4490](https://github.com/pybind/pybind11/pull/4490)\n- Ensure the tests dir does not show up with new versions of setuptools.\n [#4510](https://github.com/pybind/pybind11/pull/4510)\n- Better stacklevel for a warning in setuptools helpers.\n [#4516](https://github.com/pybind/pybind11/pull/4516)\n\n## Version 2.10.3 (Jan 3, 2023)\n\nChanges:\n\n- Temporarily made our GIL status assertions (added in 2.10.2) disabled\n by default (re-enable manually by defining\n `PYBIND11_ASSERT_GIL_HELD_INCREF_DECREF`, will be enabled in 2.11).\n [#4432](https://github.com/pybind/pybind11/pull/4432)\n- Improved error messages when `inc_ref`/`dec_ref` are called with an\n invalid GIL state.\n [#4427](https://github.com/pybind/pybind11/pull/4427)\n [#4436](https://github.com/pybind/pybind11/pull/4436)\n\nBug Fixes:\n\n- Some minor touchups found by static analyzers.\n [#4440](https://github.com/pybind/pybind11/pull/4440)\n\n## Version 2.10.2 (Dec 20, 2022)\n\nChanges:\n\n- `scoped_interpreter` constructor taking `PyConfig`.\n [#4330](https://github.com/pybind/pybind11/pull/4330)\n- `pybind11/eigen/tensor.h` adds converters to and from `Eigen::Tensor`\n and `Eigen::TensorMap`.\n [#4201](https://github.com/pybind/pybind11/pull/4201)\n- `PyGILState_Check()`'s were integrated to `pybind11::handle`\n `inc_ref()` & `dec_ref()`. The added GIL checks are guarded by\n `PYBIND11_ASSERT_GIL_HELD_INCREF_DECREF`, which is the default only if\n `NDEBUG` is not defined. (Made non-default in 2.10.3, will be active\n in 2.11) [#4246](https://github.com/pybind/pybind11/pull/4246)\n- Add option for enable/disable enum members in docstring.\n [#2768](https://github.com/pybind/pybind11/pull/2768)\n- Fixed typing of `KeysView`, `ValuesView` and `ItemsView` in\n `bind_map`. [#4353](https://github.com/pybind/pybind11/pull/4353)\n\nBug fixes:\n\n- Bug fix affecting only Python 3.6 under very specific, uncommon\n conditions: move `PyEval_InitThreads()` call to the correct location.\n [#4350](https://github.com/pybind/pybind11/pull/4350)\n- Fix segfault bug when passing foreign native functions to\n functional.h. [#4254](https://github.com/pybind/pybind11/pull/4254)\n\nBuild system improvements:\n\n- Support setting PYTHON_LIBRARIES manually for Windows ARM\n cross-compilation (classic mode).\n [#4406](https://github.com/pybind/pybind11/pull/4406)\n- Extend IPO/LTO detection for ICX (a.k.a IntelLLVM) compiler.\n [#4402](https://github.com/pybind/pybind11/pull/4402)\n- Allow calling `find_package(pybind11 CONFIG)` multiple times from\n separate directories in the same CMake project and properly link\n Python (new mode).\n [#4401](https://github.com/pybind/pybind11/pull/4401)\n- `multiprocessing_set_spawn` in pytest fixture for added safety.\n [#4377](https://github.com/pybind/pybind11/pull/4377)\n- Fixed a bug in two pybind11/tools cmake scripts causing \"Unknown\n arguments specified\" errors.\n [#4327](https://github.com/pybind/pybind11/pull/4327)\n\n## Version 2.10.1 (Oct 31, 2022)\n\nThis is the first version to fully support embedding the newly released\nPython 3.11.\n\nChanges:\n\n- Allow `pybind11::capsule` constructor to take null destructor\n pointers. [#4221](https://github.com/pybind/pybind11/pull/4221)\n- `embed.h` was changed so that `PYTHONPATH` is used also with Python\n 3.11 (established behavior).\n [#4119](https://github.com/pybind/pybind11/pull/4119)\n- A `PYBIND11_SIMPLE_GIL_MANAGEMENT` option was added (cmake, C++\n define), along with many additional tests in `test_gil_scoped.py`. The\n option may be useful to try when debugging GIL-related issues, to\n determine if the more complex default implementation is or is not to\n blame. See \\#4216 for background. WARNING: Please be careful to not\n create ODR violations when using the option: everything that is linked\n together with mutual symbol visibility needs to be rebuilt.\n [#4216](https://github.com/pybind/pybind11/pull/4216)\n- `PYBIND11_EXPORT_EXCEPTION` was made non-empty only under macOS. This\n makes Linux builds safer, and enables the removal of warning\n suppression pragmas for Windows.\n [#4298](https://github.com/pybind/pybind11/pull/4298)\n\nBug fixes:\n\n- Fixed a bug where `UnicodeDecodeError` was not propagated from various\n `py::str` ctors when decoding surrogate utf characters.\n [#4294](https://github.com/pybind/pybind11/pull/4294)\n- Revert perfect forwarding for `make_iterator`. This broke at least one\n valid use case. May revisit later.\n [#4234](https://github.com/pybind/pybind11/pull/4234)\n- Fix support for safe casts to `void*` (regression in 2.10.0).\n [#4275](https://github.com/pybind/pybind11/pull/4275)\n- Fix `char8_t` support (regression in 2.9).\n [#4278](https://github.com/pybind/pybind11/pull/4278)\n- Unicode surrogate character in Python exception message leads to\n process termination in `error_already_set::what()`.\n [#4297](https://github.com/pybind/pybind11/pull/4297)\n- Fix MSVC 2019 v.1924 & C++14 mode error for `overload_cast`.\n [#4188](https://github.com/pybind/pybind11/pull/4188)\n- Make augmented assignment operators non-const for the object-api.\n Behavior was previously broken for augmented assignment operators.\n [#4065](https://github.com/pybind/pybind11/pull/4065)\n- Add proper error checking to C++ bindings for Python list append and\n insert. [#4208](https://github.com/pybind/pybind11/pull/4208)\n- Work-around for Nvidia's CUDA nvcc compiler in versions 11.4.0 -\n 11.8.0. [#4220](https://github.com/pybind/pybind11/pull/4220)\n- A workaround for PyPy was added in the `py::error_already_set`\n implementation, related to PR\n [#1895](https://github.com/pybind/pybind11/pull/1895) released with\n v2.10.0. [#4079](https://github.com/pybind/pybind11/pull/4079)\n- Fixed compiler errors when C++23 `std::forward_like` is available.\n [#4136](https://github.com/pybind/pybind11/pull/4136)\n- Properly raise exceptions in contains methods (like when an object in\n unhashable). [#4209](https://github.com/pybind/pybind11/pull/4209)\n- Further improve another error in exception handling.\n [#4232](https://github.com/pybind/pybind11/pull/4232)\n- `get_local_internals()` was made compatible with\n `finalize_interpreter()`, fixing potential freezes during interpreter\n finalization. [#4192](https://github.com/pybind/pybind11/pull/4192)\n\nPerformance and style:\n\n- Reserve space in set and STL map casters if possible. This will\n prevent unnecessary rehashing / resizing by knowing the number of keys\n ahead of time for Python to C++ casting. This improvement will greatly\n speed up the casting of large unordered maps and sets.\n [#4194](https://github.com/pybind/pybind11/pull/4194)\n- GIL RAII scopes are non-copyable to avoid potential bugs.\n [#4183](https://github.com/pybind/pybind11/pull/4183)\n- Explicitly default all relevant ctors for pytypes in the\n `PYBIND11_OBJECT` macros and enforce the clang-tidy checks\n `modernize-use-equals-default` in macros as well.\n [#4017](https://github.com/pybind/pybind11/pull/4017)\n- Optimize iterator advancement in C++ bindings.\n [#4237](https://github.com/pybind/pybind11/pull/4237)\n- Use the modern `PyObject_GenericGetDict` and `PyObject_GenericSetDict`\n for handling dynamic attribute dictionaries.\n [#4106](https://github.com/pybind/pybind11/pull/4106)\n- Document that users should use `PYBIND11_NAMESPACE` instead of using\n `pybind11` when opening namespaces. Using namespace declarations and\n namespace qualification remain the same as `pybind11`. This is done to\n ensure consistent symbol visibility.\n [#4098](https://github.com/pybind/pybind11/pull/4098)\n- Mark `detail::forward_like` as constexpr.\n [#4147](https://github.com/pybind/pybind11/pull/4147)\n- Optimize unpacking_collector when processing `arg_v` arguments.\n [#4219](https://github.com/pybind/pybind11/pull/4219)\n- Optimize casting C++ object to `None`.\n [#4269](https://github.com/pybind/pybind11/pull/4269)\n\nBuild system improvements:\n\n- CMake: revert overwrite behavior, now opt-in with\n `PYBIND11_PYTHONLIBS_OVERRWRITE OFF`.\n [#4195](https://github.com/pybind/pybind11/pull/4195)\n- Include a pkg-config file when installing pybind11, such as in the\n Python package. [#4077](https://github.com/pybind/pybind11/pull/4077)\n- Avoid stripping debug symbols when `CMAKE_BUILD_TYPE` is set to\n `DEBUG` instead of `Debug`.\n [#4078](https://github.com/pybind/pybind11/pull/4078)\n- Followup to [#3948](https://github.com/pybind/pybind11/pull/3948),\n fixing vcpkg again.\n [#4123](https://github.com/pybind/pybind11/pull/4123)\n\n## Version 2.10.0 (Jul 15, 2022)\n\nRemoved support for Python 2.7, Python 3.5, and MSVC 2015. Support for\nMSVC 2017 is limited due to availability of CI runners; we highly\nrecommend MSVC 2019 or 2022 be used. Initial support added for Python\n3.11.\n\nNew features:\n\n- `py::anyset` & `py::frozenset` were added, with copying (cast) to\n `std::set` (similar to `set`).\n [#3901](https://github.com/pybind/pybind11/pull/3901)\n- Support bytearray casting to string.\n [#3707](https://github.com/pybind/pybind11/pull/3707)\n- `type_caster` was added. `std::monostate` is a tag\n type that allows `std::variant` to act as an optional, or allows\n default construction of a `std::variant` holding a non-default\n constructible type.\n [#3818](https://github.com/pybind/pybind11/pull/3818)\n- `pybind11::capsule::set_name` added to mutate the name of the capsule\n instance. [#3866](https://github.com/pybind/pybind11/pull/3866)\n- NumPy: dtype constructor from type number added, accessors\n corresponding to Python API `dtype.num`, `dtype.byteorder`,\n `dtype.flags` and `dtype.alignment` added.\n [#3868](https://github.com/pybind/pybind11/pull/3868)\n\nChanges:\n\n- Python 3.6 is now the minimum supported version.\n [#3688](https://github.com/pybind/pybind11/pull/3688)\n [#3719](https://github.com/pybind/pybind11/pull/3719)\n- The minimum version for MSVC is now 2017.\n [#3722](https://github.com/pybind/pybind11/pull/3722)\n- Fix issues with CPython 3.11 betas and add to supported test matrix.\n [#3923](https://github.com/pybind/pybind11/pull/3923)\n- `error_already_set` is now safer and more performant, especially for\n exceptions with long tracebacks, by delaying computation.\n [#1895](https://github.com/pybind/pybind11/pull/1895)\n- Improve exception handling in python `str` bindings.\n [#3826](https://github.com/pybind/pybind11/pull/3826)\n- The bindings for capsules now have more consistent exception handling.\n [#3825](https://github.com/pybind/pybind11/pull/3825)\n- `PYBIND11_OBJECT_CVT` and `PYBIND11_OBJECT_CVT_DEFAULT` macro can now\n be used to define classes in namespaces other than pybind11.\n [#3797](https://github.com/pybind/pybind11/pull/3797)\n- Error printing code now uses `PYBIND11_DETAILED_ERROR_MESSAGES`\n instead of requiring `NDEBUG`, allowing use with release builds if\n desired. [#3913](https://github.com/pybind/pybind11/pull/3913)\n- Implicit conversion of the literal `0` to `pybind11::handle` is now\n disabled. [#4008](https://github.com/pybind/pybind11/pull/4008)\n\nBug fixes:\n\n- Fix exception handling when `pybind11::weakref()` fails.\n [#3739](https://github.com/pybind/pybind11/pull/3739)\n- `module_::def_submodule` was missing proper error handling. This is\n fixed now. [#3973](https://github.com/pybind/pybind11/pull/3973)\n- The behavior or `error_already_set` was made safer and the highly\n opaque \"Unknown internal error occurred\" message was replaced with a\n more helpful message.\n [#3982](https://github.com/pybind/pybind11/pull/3982)\n- `error_already_set::what()` now handles non-normalized exceptions\n correctly. [#3971](https://github.com/pybind/pybind11/pull/3971)\n- Support older C++ compilers where filesystem is not yet part of the\n standard library and is instead included in\n `std::experimental::filesystem`.\n [#3840](https://github.com/pybind/pybind11/pull/3840)\n- Fix `-Wfree-nonheap-object` warnings produced by GCC by avoiding\n returning pointers to static objects with\n `return_value_policy::take_ownership`.\n [#3946](https://github.com/pybind/pybind11/pull/3946)\n- Fix cast from pytype rvalue to another pytype.\n [#3949](https://github.com/pybind/pybind11/pull/3949)\n- Ensure proper behavior when garbage collecting classes with dynamic\n attributes in Python \\>=3.9.\n [#4051](https://github.com/pybind/pybind11/pull/4051)\n- A couple long-standing `PYBIND11_NAMESPACE`\n `__attribute__((visibility(\"hidden\")))` inconsistencies are now fixed\n (affects only unusual environments).\n [#4043](https://github.com/pybind/pybind11/pull/4043)\n- `pybind11::detail::get_internals()` is now resilient to in-flight\n Python exceptions.\n [#3981](https://github.com/pybind/pybind11/pull/3981)\n- Arrays with a dimension of size 0 are now properly converted to\n dynamic Eigen matrices (more common in NumPy 1.23).\n [#4038](https://github.com/pybind/pybind11/pull/4038)\n- Avoid catching unrelated errors when importing NumPy.\n [#3974](https://github.com/pybind/pybind11/pull/3974)\n\nPerformance and style:\n\n- Added an accessor overload of `(object &&key)` to reference steal the\n object when using python types as keys. This prevents unnecessary\n reference count overhead for attr, dictionary, tuple, and sequence\n look ups. Added additional regression tests. Fixed a performance bug\n the caused accessor assignments to potentially perform unnecessary\n copies. [#3970](https://github.com/pybind/pybind11/pull/3970)\n- Perfect forward all args of `make_iterator`.\n [#3980](https://github.com/pybind/pybind11/pull/3980)\n- Avoid potential bug in pycapsule destructor by adding an `error_guard`\n to one of the dtors.\n [#3958](https://github.com/pybind/pybind11/pull/3958)\n- Optimize dictionary access in `strip_padding` for numpy.\n [#3994](https://github.com/pybind/pybind11/pull/3994)\n- `stl_bind.h` bindings now take slice args as a const-ref.\n [#3852](https://github.com/pybind/pybind11/pull/3852)\n- Made slice constructor more consistent, and improve performance of\n some casters by allowing reference stealing.\n [#3845](https://github.com/pybind/pybind11/pull/3845)\n- Change numpy dtype from_args method to use const ref.\n [#3878](https://github.com/pybind/pybind11/pull/3878)\n- Follow rule of three to ensure `PyErr_Restore` is called only once.\n [#3872](https://github.com/pybind/pybind11/pull/3872)\n- Added missing perfect forwarding for `make_iterator` functions.\n [#3860](https://github.com/pybind/pybind11/pull/3860)\n- Optimize c++ to python function casting by using the rvalue caster.\n [#3966](https://github.com/pybind/pybind11/pull/3966)\n- Optimize Eigen sparse matrix casting by removing unnecessary\n temporary. [#4064](https://github.com/pybind/pybind11/pull/4064)\n- Avoid potential implicit copy/assignment constructors causing double\n free in `strdup_guard`.\n [#3905](https://github.com/pybind/pybind11/pull/3905)\n- Enable clang-tidy checks `misc-definitions-in-headers`,\n `modernize-loop-convert`, and `modernize-use-nullptr`.\n [#3881](https://github.com/pybind/pybind11/pull/3881)\n [#3988](https://github.com/pybind/pybind11/pull/3988)\n\nBuild system improvements:\n\n- CMake: Fix file extension on Windows with cp36 and cp37 using\n FindPython. [#3919](https://github.com/pybind/pybind11/pull/3919)\n- CMake: Support multiple Python targets (such as on vcpkg).\n [#3948](https://github.com/pybind/pybind11/pull/3948)\n- CMake: Fix issue with NVCC on Windows.\n [#3947](https://github.com/pybind/pybind11/pull/3947)\n- CMake: Drop the bitness check on cross compiles (like targeting\n WebAssembly via Emscripten).\n [#3959](https://github.com/pybind/pybind11/pull/3959)\n- Add MSVC builds in debug mode to CI.\n [#3784](https://github.com/pybind/pybind11/pull/3784)\n- MSVC 2022 C++20 coverage was added to GitHub Actions, including Eigen.\n [#3732](https://github.com/pybind/pybind11/pull/3732),\n [#3741](https://github.com/pybind/pybind11/pull/3741)\n\nBackend and tidying up:\n\n- New theme for the documentation.\n [#3109](https://github.com/pybind/pybind11/pull/3109)\n- Remove idioms in code comments. Use more inclusive language.\n [#3809](https://github.com/pybind/pybind11/pull/3809)\n- `#include ` was removed from the `pybind11/stl.h` header.\n Your project may break if it has a transitive dependency on this\n include. The fix is to \"Include What You Use\".\n [#3928](https://github.com/pybind/pybind11/pull/3928)\n- Avoid `setup.py ` usage in internal tests.\n [#3734](https://github.com/pybind/pybind11/pull/3734)\n\n## Version 2.9.2 (Mar 29, 2022)\n\nChanges:\n\n- Enum now has an `__index__` method on Python \\<3.8 too.\n [#3700](https://github.com/pybind/pybind11/pull/3700)\n- Local internals are now cleared after finalizing the interpreter.\n [#3744](https://github.com/pybind/pybind11/pull/3744)\n\nBug fixes:\n\n- Better support for Python 3.11 alphas.\n [#3694](https://github.com/pybind/pybind11/pull/3694)\n- `PYBIND11_TYPE_CASTER` now uses fully qualified symbols, so it can be\n used outside of `pybind11::detail`.\n [#3758](https://github.com/pybind/pybind11/pull/3758)\n- Some fixes for PyPy 3.9.\n [#3768](https://github.com/pybind/pybind11/pull/3768)\n- Fixed a potential memleak in PyPy in `get_type_override`.\n [#3774](https://github.com/pybind/pybind11/pull/3774)\n- Fix usage of `VISIBILITY_INLINES_HIDDEN`.\n [#3721](https://github.com/pybind/pybind11/pull/3721)\n\nBuild system improvements:\n\n- Uses `sysconfig` module to determine installation locations on Python\n \\>= 3.10, instead of `distutils` which has been deprecated.\n [#3764](https://github.com/pybind/pybind11/pull/3764)\n- Support Catch 2.13.5+ (supporting GLIBC 2.34+).\n [#3679](https://github.com/pybind/pybind11/pull/3679)\n- Fix test failures with numpy 1.22 by ignoring whitespace when\n comparing `str()` of dtypes.\n [#3682](https://github.com/pybind/pybind11/pull/3682)\n\nBackend and tidying up:\n\n- clang-tidy: added `readability-qualified-auto`,\n `readability-braces-around-statements`,\n `cppcoreguidelines-prefer-member-initializer`,\n `clang-analyzer-optin.performance.Padding`,\n `cppcoreguidelines-pro-type-static-cast-downcast`, and\n `readability-inconsistent-declaration-parameter-name`.\n [#3702](https://github.com/pybind/pybind11/pull/3702),\n [#3699](https://github.com/pybind/pybind11/pull/3699),\n [#3716](https://github.com/pybind/pybind11/pull/3716),\n [#3709](https://github.com/pybind/pybind11/pull/3709)\n- clang-format was added to the pre-commit actions, and the entire code\n base automatically reformatted (after several iterations preparing for\n this leap). [#3713](https://github.com/pybind/pybind11/pull/3713)\n\n## Version 2.9.1 (Feb 2, 2022)\n\nChanges:\n\n- If possible, attach Python exception with `py::raise_from` to\n `TypeError` when casting from C++ to Python. This will give additional\n info if Python exceptions occur in the caster. Adds a test case of\n trying to convert a set from C++ to Python when the hash function is\n not defined in Python.\n [#3605](https://github.com/pybind/pybind11/pull/3605)\n- Add a mapping of C++11 nested exceptions to their Python exception\n equivalent using `py::raise_from`. This attaches the nested exceptions\n in Python using the `__cause__` field.\n [#3608](https://github.com/pybind/pybind11/pull/3608)\n- Propagate Python exception traceback using `raise_from` if a pybind11\n function runs out of overloads.\n [#3671](https://github.com/pybind/pybind11/pull/3671)\n- `py::multiple_inheritance` is now only needed when C++ bases are\n hidden from pybind11.\n [#3650](https://github.com/pybind/pybind11/pull/3650) and\n [#3659](https://github.com/pybind/pybind11/pull/3659)\n\nBug fixes:\n\n- Remove a boolean cast in `numpy.h` that causes MSVC C4800 warnings\n when compiling against Python 3.10 or newer.\n [#3669](https://github.com/pybind/pybind11/pull/3669)\n- Render `py::bool_` and `py::float_` as `bool` and `float`\n respectively. [#3622](https://github.com/pybind/pybind11/pull/3622)\n\nBuild system improvements:\n\n- Fix CMake extension suffix computation on Python 3.10+.\n [#3663](https://github.com/pybind/pybind11/pull/3663)\n- Allow `CMAKE_ARGS` to override CMake args in pybind11's own\n `setup.py`. [#3577](https://github.com/pybind/pybind11/pull/3577)\n- Remove a few deprecated c-headers.\n [#3610](https://github.com/pybind/pybind11/pull/3610)\n- More uniform handling of test targets.\n [#3590](https://github.com/pybind/pybind11/pull/3590)\n- Add clang-tidy readability check to catch potentially swapped function\n args. [#3611](https://github.com/pybind/pybind11/pull/3611)\n\n## Version 2.9.0 (Dec 28, 2021)\n\nThis is the last version to support Python 2.7 and 3.5.\n\nNew Features:\n\n- Allow `py::args` to be followed by other arguments; the remaining\n arguments are implicitly keyword-only, as if a `py::kw_only{}`\n annotation had been used.\n [#3402](https://github.com/pybind/pybind11/pull/3402)\n\nChanges:\n\n- Make str/bytes/memoryview more interoperable with `std::string_view`.\n [#3521](https://github.com/pybind/pybind11/pull/3521)\n- Replace `_` with `const_name` in internals, avoid defining `pybind::_`\n if `_` defined as macro (common gettext usage)\n [#3423](https://github.com/pybind/pybind11/pull/3423)\n\nBug fixes:\n\n- Fix a rare warning about extra copy in an Eigen constructor.\n [#3486](https://github.com/pybind/pybind11/pull/3486)\n- Fix caching of the C++ overrides.\n [#3465](https://github.com/pybind/pybind11/pull/3465)\n- Add missing `std::forward` calls to some `cpp_function` overloads.\n [#3443](https://github.com/pybind/pybind11/pull/3443)\n- Support PyPy 7.3.7 and the PyPy3.8 beta. Test python-3.11 on PRs with\n the `python dev` label.\n [#3419](https://github.com/pybind/pybind11/pull/3419)\n- Replace usage of deprecated `Eigen::MappedSparseMatrix` with\n `Eigen::Map>` for Eigen 3.3+.\n [#3499](https://github.com/pybind/pybind11/pull/3499)\n- Tweaks to support Microsoft Visual Studio 2022.\n [#3497](https://github.com/pybind/pybind11/pull/3497)\n\nBuild system improvements:\n\n- Nicer CMake printout and IDE organisation for pybind11's own tests.\n [#3479](https://github.com/pybind/pybind11/pull/3479)\n- CMake: report version type as part of the version string to avoid a\n spurious space in the package status message.\n [#3472](https://github.com/pybind/pybind11/pull/3472)\n- Flags starting with `-g` in `$CFLAGS` and `$CPPFLAGS` are no longer\n overridden by `.Pybind11Extension`.\n [#3436](https://github.com/pybind/pybind11/pull/3436)\n- Ensure ThreadPool is closed in `setup_helpers`.\n [#3548](https://github.com/pybind/pybind11/pull/3548)\n- Avoid LTS on `mips64` and `ppc64le` (reported broken).\n [#3557](https://github.com/pybind/pybind11/pull/3557)\n\n## v2.8.1 (Oct 27, 2021)\n\nChanges and additions:\n\n- The simple namespace creation shortcut added in 2.8.0 was deprecated\n due to usage of CPython internal API, and will be removed soon. Use\n `py::module_::import(\"types\").attr(\"SimpleNamespace\")`.\n [#3374](https://github.com/pybinyyd/pybind11/pull/3374)\n- Add C++ Exception type to throw and catch `AttributeError`. Useful for\n defining custom `__setattr__` and `__getattr__` methods.\n [#3387](https://github.com/pybind/pybind11/pull/3387)\n\nFixes:\n\n- Fixed the potential for dangling references when using properties with\n `std::optional` types.\n [#3376](https://github.com/pybind/pybind11/pull/3376)\n- Modernize usage of `PyCodeObject` on Python 3.9+ (moving toward\n support for Python 3.11a1)\n [#3368](https://github.com/pybind/pybind11/pull/3368)\n- A long-standing bug in `eigen.h` was fixed (originally PR \\#3343). The\n bug was unmasked by newly added `static_assert`'s in the Eigen 3.4.0\n release. [#3352](https://github.com/pybind/pybind11/pull/3352)\n- Support multiple raw inclusion of CMake helper files (Conan.io does\n this for multi-config generators).\n [#3420](https://github.com/pybind/pybind11/pull/3420)\n- Fix harmless warning on upcoming CMake 3.22.\n [#3368](https://github.com/pybind/pybind11/pull/3368)\n- Fix 2.8.0 regression with MSVC 2017 + C++17 mode + Python 3.\n [#3407](https://github.com/pybind/pybind11/pull/3407)\n- Fix 2.8.0 regression that caused undefined behavior (typically\n segfaults) in `make_key_iterator`/`make_value_iterator` if\n dereferencing the iterator returned a temporary value instead of a\n reference. [#3348](https://github.com/pybind/pybind11/pull/3348)\n\n## v2.8.0 (Oct 4, 2021)\n\nNew features:\n\n- Added `py::raise_from` to enable chaining exceptions.\n [#3215](https://github.com/pybind/pybind11/pull/3215)\n- Allow exception translators to be optionally registered local to a\n module instead of applying globally across all pybind11 modules. Use\n `register_local_exception_translator(ExceptionTranslator&& translator)`\n instead of\n `register_exception_translator(ExceptionTranslator&& translator)` to\n keep your exception remapping code local to the module.\n [#2650](https://github.com/pybinyyd/pybind11/pull/2650)\n- Add `make_simple_namespace` function for instantiating Python\n `SimpleNamespace` objects. **Deprecated in 2.8.1.**\n [#2840](https://github.com/pybind/pybind11/pull/2840)\n- `pybind11::scoped_interpreter` and `initialize_interpreter` have new\n arguments to allow `sys.argv` initialization.\n [#2341](https://github.com/pybind/pybind11/pull/2341)\n- Allow Python builtins to be used as callbacks in CPython.\n [#1413](https://github.com/pybind/pybind11/pull/1413)\n- Added `view` to view arrays with a different datatype.\n [#987](https://github.com/pybind/pybind11/pull/987)\n- Implemented `reshape` on arrays.\n [#984](https://github.com/pybind/pybind11/pull/984)\n- Enable defining custom `__new__` methods on classes by fixing bug\n preventing overriding methods if they have non-pybind11 siblings.\n [#3265](https://github.com/pybind/pybind11/pull/3265)\n- Add `make_value_iterator()`, and fix `make_key_iterator()` to return\n references instead of copies.\n [#3293](https://github.com/pybind/pybind11/pull/3293)\n- Improve the classes generated by `bind_map`:\n [#3310](https://github.com/pybind/pybind11/pull/3310)\n - Change `.items` from an iterator to a dictionary view.\n - Add `.keys` and `.values` (both dictionary views).\n - Allow `__contains__` to take any object.\n- `pybind11::custom_type_setup` was added, for customizing the\n `PyHeapTypeObject` corresponding to a class, which may be useful for\n enabling garbage collection support, among other things.\n [#3287](https://github.com/pybind/pybind11/pull/3287)\n\nChanges:\n\n- Set `__file__` constant when running `eval_file` in an embedded\n interpreter. [#3233](https://github.com/pybind/pybind11/pull/3233)\n- Python objects and (C++17) `std::optional` now accepted in `py::slice`\n constructor. [#1101](https://github.com/pybind/pybind11/pull/1101)\n- The pybind11 proxy types `str`, `bytes`, `bytearray`, `tuple`, `list`\n now consistently support passing `ssize_t` values for sizes and\n indexes. Previously, only `size_t` was accepted in several interfaces.\n [#3219](https://github.com/pybind/pybind11/pull/3219)\n- Avoid evaluating `PYBIND11_TLS_REPLACE_VALUE` arguments more than\n once. [#3290](https://github.com/pybind/pybind11/pull/3290)\n\nFixes:\n\n- Bug fix: enum value's `__int__` returning non-int when underlying type\n is bool or of char type.\n [#1334](https://github.com/pybind/pybind11/pull/1334)\n- Fixes bug in setting error state in Capsule's pointer methods.\n [#3261](https://github.com/pybind/pybind11/pull/3261)\n- A long-standing memory leak in `py::cpp_function::initialize` was\n fixed. [#3229](https://github.com/pybind/pybind11/pull/3229)\n- Fixes thread safety for some `pybind11::type_caster` which require\n lifetime extension, such as for `std::string_view`.\n [#3237](https://github.com/pybind/pybind11/pull/3237)\n- Restore compatibility with gcc 4.8.4 as distributed by ubuntu-trusty,\n linuxmint-17. [#3270](https://github.com/pybind/pybind11/pull/3270)\n\nBuild system improvements:\n\n- Fix regression in CMake Python package config: improper use of\n absolute path. [#3144](https://github.com/pybind/pybind11/pull/3144)\n- Cached Python version information could become stale when CMake was\n re-run with a different Python version. The build system now detects\n this and updates this information.\n [#3299](https://github.com/pybind/pybind11/pull/3299)\n- Specified UTF8-encoding in setup.py calls of open().\n [#3137](https://github.com/pybind/pybind11/pull/3137)\n- Fix a harmless warning from CMake 3.21 with the classic Python\n discovery. [#3220](https://github.com/pybind/pybind11/pull/3220)\n- Eigen repo and version can now be specified as cmake options.\n [#3324](https://github.com/pybind/pybind11/pull/3324)\n\nBackend and tidying up:\n\n- Reduced thread-local storage required for keeping alive temporary data\n for type conversion to one key per ABI version, rather than one key\n per extension module. This makes the total thread-local storage\n required by pybind11 2 keys per ABI version.\n [#3275](https://github.com/pybind/pybind11/pull/3275)\n- Optimize NumPy array construction with additional moves.\n [#3183](https://github.com/pybind/pybind11/pull/3183)\n- Conversion to `std::string` and `std::string_view` now avoids making\n an extra copy of the data on Python \\>= 3.3.\n [#3257](https://github.com/pybind/pybind11/pull/3257)\n- Remove const modifier from certain C++ methods on Python collections\n (`list`, `set`, `dict`) such as (`clear()`, `append()`, `insert()`,\n etc...) and annotated them with `py-non-const`.\n- Enable readability `clang-tidy-const-return` and remove useless\n consts. [#3254](https://github.com/pybind/pybind11/pull/3254)\n [#3194](https://github.com/pybind/pybind11/pull/3194)\n- The clang-tidy `google-explicit-constructor` option was enabled.\n [#3250](https://github.com/pybind/pybind11/pull/3250)\n- Mark a pytype move constructor as noexcept (perf).\n [#3236](https://github.com/pybind/pybind11/pull/3236)\n- Enable clang-tidy check to guard against inheritance slicing.\n [#3210](https://github.com/pybind/pybind11/pull/3210)\n- Legacy warning suppression pragma were removed from eigen.h. On Unix\n platforms, please use -isystem for Eigen include directories, to\n suppress compiler warnings originating from Eigen headers. Note that\n CMake does this by default. No adjustments are needed for Windows.\n [#3198](https://github.com/pybind/pybind11/pull/3198)\n- Format pybind11 with isort consistent ordering of imports\n [#3195](https://github.com/pybind/pybind11/pull/3195)\n- The warnings-suppression \"pragma clamp\" at the top/bottom of pybind11\n was removed, clearing the path to refactoring and IWYU cleanup.\n [#3186](https://github.com/pybind/pybind11/pull/3186)\n- Enable most bugprone checks in clang-tidy and fix the found potential\n bugs and poor coding styles.\n [#3166](https://github.com/pybind/pybind11/pull/3166)\n- Add `clang-tidy-readability` rules to make boolean casts explicit\n improving code readability. Also enabled other misc and readability\n clang-tidy checks.\n [#3148](https://github.com/pybind/pybind11/pull/3148)\n- Move object in `.pop()` for list.\n [#3116](https://github.com/pybind/pybind11/pull/3116)\n\n## v2.7.1 (Aug 3, 2021)\n\nMinor missing functionality added:\n\n- Allow Python builtins to be used as callbacks in CPython.\n [#1413](https://github.com/pybind/pybind11/pull/1413)\n\nBug fixes:\n\n- Fix regression in CMake Python package config: improper use of\n absolute path. [#3144](https://github.com/pybind/pybind11/pull/3144)\n- Fix Mingw64 and add to the CI testing matrix.\n [#3132](https://github.com/pybind/pybind11/pull/3132)\n- Specified UTF8-encoding in setup.py calls of open().\n [#3137](https://github.com/pybind/pybind11/pull/3137)\n- Add clang-tidy-readability rules to make boolean casts explicit\n improving code readability. Also enabled other misc and readability\n clang-tidy checks.\n [#3148](https://github.com/pybind/pybind11/pull/3148)\n- Move object in `.pop()` for list.\n [#3116](https://github.com/pybind/pybind11/pull/3116)\n\nBackend and tidying up:\n\n- Removed and fixed warning suppressions.\n [#3127](https://github.com/pybind/pybind11/pull/3127)\n [#3129](https://github.com/pybind/pybind11/pull/3129)\n [#3135](https://github.com/pybind/pybind11/pull/3135)\n [#3141](https://github.com/pybind/pybind11/pull/3141)\n [#3142](https://github.com/pybind/pybind11/pull/3142)\n [#3150](https://github.com/pybind/pybind11/pull/3150)\n [#3152](https://github.com/pybind/pybind11/pull/3152)\n [#3160](https://github.com/pybind/pybind11/pull/3160)\n [#3161](https://github.com/pybind/pybind11/pull/3161)\n\n## v2.7.0 (Jul 16, 2021)\n\nNew features:\n\n- Enable `py::implicitly_convertible` for\n `py::class_`-wrapped types.\n [#3059](https://github.com/pybind/pybind11/pull/3059)\n- Allow function pointer extraction from overloaded functions.\n [#2944](https://github.com/pybind/pybind11/pull/2944)\n- NumPy: added `.char_()` to type which gives the NumPy public `char`\n result, which also distinguishes types by bit length (unlike\n `.kind()`). [#2864](https://github.com/pybind/pybind11/pull/2864)\n- Add `pybind11::bytearray` to manipulate `bytearray` similar to\n `bytes`. [#2799](https://github.com/pybind/pybind11/pull/2799)\n- `pybind11/stl/filesystem.h` registers a type caster that, on\n C++17/Python 3.6+, converts `std::filesystem::path` to `pathlib.Path`\n and any `os.PathLike` to `std::filesystem::path`.\n [#2730](https://github.com/pybind/pybind11/pull/2730)\n- A `PYBIND11_VERSION_HEX` define was added, similar to\n `PY_VERSION_HEX`.\n [#3120](https://github.com/pybind/pybind11/pull/3120)\n\nChanges:\n\n- `py::str` changed to exclusively hold `PyUnicodeObject`. Previously\n `py::str` could also hold `bytes`, which is probably surprising, was\n never documented, and can mask bugs (e.g. accidental use of `py::str`\n instead of `py::bytes`).\n [#2409](https://github.com/pybind/pybind11/pull/2409)\n- Add a safety guard to ensure that the Python GIL is held when C++\n calls back into Python via `object_api<>::operator()` (e.g.\n `py::function` `__call__`). (This feature is available for Python 3.6+\n only.) [#2919](https://github.com/pybind/pybind11/pull/2919)\n- Catch a missing `self` argument in calls to `__init__()`.\n [#2914](https://github.com/pybind/pybind11/pull/2914)\n- Use `std::string_view` if available to avoid a copy when passing an\n object to a `std::ostream`.\n [#3042](https://github.com/pybind/pybind11/pull/3042)\n- An important warning about thread safety was added to the `iostream.h`\n documentation; attempts to make `py::scoped_ostream_redirect` thread\n safe have been removed, as it was only partially effective.\n [#2995](https://github.com/pybind/pybind11/pull/2995)\n\nFixes:\n\n- Performance: avoid unnecessary strlen calls.\n [#3058](https://github.com/pybind/pybind11/pull/3058)\n- Fix auto-generated documentation string when using `const T` in\n `pyarray_t`. [#3020](https://github.com/pybind/pybind11/pull/3020)\n- Unify error messages thrown by\n `simple_collector`/`unpacking_collector`.\n [#3013](https://github.com/pybind/pybind11/pull/3013)\n- `pybind11::builtin_exception` is now explicitly exported, which means\n the types included/defined in different modules are identical, and\n exceptions raised in different modules can be caught correctly. The\n documentation was updated to explain that custom exceptions that are\n used across module boundaries need to be explicitly exported as well.\n [#2999](https://github.com/pybind/pybind11/pull/2999)\n- Fixed exception when printing UTF-8 to a `scoped_ostream_redirect`.\n [#2982](https://github.com/pybind/pybind11/pull/2982)\n- Pickle support enhancement: `setstate` implementation will attempt to\n `setattr` `__dict__` only if the unpickled `dict` object is not empty,\n to not force use of `py::dynamic_attr()` unnecessarily.\n [#2972](https://github.com/pybind/pybind11/pull/2972)\n- Allow negative timedelta values to roundtrip.\n [#2870](https://github.com/pybind/pybind11/pull/2870)\n- Fix unchecked errors could potentially swallow signals/other\n exceptions. [#2863](https://github.com/pybind/pybind11/pull/2863)\n- Add null pointer check with `std::localtime`.\n [#2846](https://github.com/pybind/pybind11/pull/2846)\n- Fix the `weakref` constructor from `py::object` to create a new\n `weakref` on conversion.\n [#2832](https://github.com/pybind/pybind11/pull/2832)\n- Avoid relying on exceptions in C++17 when getting a `shared_ptr`\n holder from a `shared_from_this` class.\n [#2819](https://github.com/pybind/pybind11/pull/2819)\n- Allow the codec's exception to be raised instead of `RuntimeError`\n when casting from `py::str` to `std::string`.\n [#2903](https://github.com/pybind/pybind11/pull/2903)\n\nBuild system improvements:\n\n- In `setup_helpers.py`, test for platforms that have some\n multiprocessing features but lack semaphores, which `ParallelCompile`\n requires. [#3043](https://github.com/pybind/pybind11/pull/3043)\n- Fix `pybind11_INCLUDE_DIR` in case `CMAKE_INSTALL_INCLUDEDIR` is\n absolute. [#3005](https://github.com/pybind/pybind11/pull/3005)\n- Fix bug not respecting `WITH_SOABI` or `WITHOUT_SOABI` to CMake.\n [#2938](https://github.com/pybind/pybind11/pull/2938)\n- Fix the default `Pybind11Extension` compilation flags with a Mingw64\n python. [#2921](https://github.com/pybind/pybind11/pull/2921)\n- Clang on Windows: do not pass `/MP` (ignored flag).\n [#2824](https://github.com/pybind/pybind11/pull/2824)\n- `pybind11.setup_helpers.intree_extensions` can be used to generate\n `Pybind11Extension` instances from cpp files placed in the Python\n package source tree.\n [#2831](https://github.com/pybind/pybind11/pull/2831)\n\nBackend and tidying up:\n\n- Enable clang-tidy performance, readability, and modernization checks\n throughout the codebase to enforce best coding practices.\n [#3046](https://github.com/pybind/pybind11/pull/3046),\n [#3049](https://github.com/pybind/pybind11/pull/3049),\n [#3051](https://github.com/pybind/pybind11/pull/3051),\n [#3052](https://github.com/pybind/pybind11/pull/3052),\n [#3080](https://github.com/pybind/pybind11/pull/3080), and\n [#3094](https://github.com/pybind/pybind11/pull/3094)\n- Checks for common misspellings were added to the pre-commit hooks.\n [#3076](https://github.com/pybind/pybind11/pull/3076)\n- Changed `Werror` to stricter `Werror-all` for Intel compiler and fixed\n minor issues. [#2948](https://github.com/pybind/pybind11/pull/2948)\n- Fixed compilation with GCC \\< 5 when the user defines\n `_GLIBCXX_USE_CXX11_ABI`.\n [#2956](https://github.com/pybind/pybind11/pull/2956)\n- Added nox support for easier local testing and linting of\n contributions. [#3101](https://github.com/pybind/pybind11/pull/3101)\n and [#3121](https://github.com/pybind/pybind11/pull/3121)\n- Avoid RTD style issue with docutils 0.17+.\n [#3119](https://github.com/pybind/pybind11/pull/3119)\n- Support pipx run, such as `pipx run pybind11 --include` for a quick\n compile. [#3117](https://github.com/pybind/pybind11/pull/3117)\n\n## v2.6.2 (Jan 26, 2021)\n\nMinor missing functionality added:\n\n- enum: add missing Enum.value property.\n [#2739](https://github.com/pybind/pybind11/pull/2739)\n- Allow thread termination to be avoided during shutdown for CPython\n 3.7+ via `.disarm` for `gil_scoped_acquire`/`gil_scoped_release`.\n [#2657](https://github.com/pybind/pybind11/pull/2657)\n\nFixed or improved behavior in a few special cases:\n\n- Fix bug where the constructor of `object` subclasses would not throw\n on being passed a Python object of the wrong type.\n [#2701](https://github.com/pybind/pybind11/pull/2701)\n- The `type_caster` for integers does not convert Python objects with\n `__int__` anymore with `noconvert` or during the first round of trying\n overloads. [#2698](https://github.com/pybind/pybind11/pull/2698)\n- When casting to a C++ integer, `__index__` is always called and not\n considered as conversion, consistent with Python 3.8+.\n [#2801](https://github.com/pybind/pybind11/pull/2801)\n\nBuild improvements:\n\n- Setup helpers: `extra_compile_args` and `extra_link_args`\n automatically set by Pybind11Extension are now prepended, which allows\n them to be overridden by user-set `extra_compile_args` and\n `extra_link_args`.\n [#2808](https://github.com/pybind/pybind11/pull/2808)\n- Setup helpers: Don't trigger unused parameter warning.\n [#2735](https://github.com/pybind/pybind11/pull/2735)\n- CMake: Support running with `--warn-uninitialized` active.\n [#2806](https://github.com/pybind/pybind11/pull/2806)\n- CMake: Avoid error if included from two submodule directories.\n [#2804](https://github.com/pybind/pybind11/pull/2804)\n- CMake: Fix `STATIC` / `SHARED` being ignored in FindPython mode.\n [#2796](https://github.com/pybind/pybind11/pull/2796)\n- CMake: Respect the setting for `CMAKE_CXX_VISIBILITY_PRESET` if\n defined. [#2793](https://github.com/pybind/pybind11/pull/2793)\n- CMake: Fix issue with FindPython2/FindPython3 not working with\n `pybind11::embed`.\n [#2662](https://github.com/pybind/pybind11/pull/2662)\n- CMake: mixing local and installed pybind11's would prioritize the\n installed one over the local one (regression in 2.6.0).\n [#2716](https://github.com/pybind/pybind11/pull/2716)\n\nBug fixes:\n\n- Fixed segfault in multithreaded environments when using\n `scoped_ostream_redirect`.\n [#2675](https://github.com/pybind/pybind11/pull/2675)\n- Leave docstring unset when all docstring-related options are disabled,\n rather than set an empty string.\n [#2745](https://github.com/pybind/pybind11/pull/2745)\n- The module key in builtins that pybind11 uses to store its internals\n changed from std::string to a python str type (more natural on Python\n 2, no change on Python 3).\n [#2814](https://github.com/pybind/pybind11/pull/2814)\n- Fixed assertion error related to unhandled (later overwritten)\n exception in CPython 3.8 and 3.9 debug builds.\n [#2685](https://github.com/pybind/pybind11/pull/2685)\n- Fix `py::gil_scoped_acquire` assert with CPython 3.9 debug build.\n [#2683](https://github.com/pybind/pybind11/pull/2683)\n- Fix issue with a test failing on pytest 6.2.\n [#2741](https://github.com/pybind/pybind11/pull/2741)\n\nWarning fixes:\n\n- Fix warning modifying constructor parameter 'flag' that shadows a\n field of 'set_flag' `[-Wshadow-field-in-constructor-modified]`.\n [#2780](https://github.com/pybind/pybind11/pull/2780)\n- Suppressed some deprecation warnings about old-style\n `__init__`/`__setstate__` in the tests.\n [#2759](https://github.com/pybind/pybind11/pull/2759)\n\nValgrind work:\n\n- Fix invalid access when calling a pybind11 `__init__` on a\n non-pybind11 class instance.\n [#2755](https://github.com/pybind/pybind11/pull/2755)\n- Fixed various minor memory leaks in pybind11's test suite.\n [#2758](https://github.com/pybind/pybind11/pull/2758)\n- Resolved memory leak in cpp_function initialization when exceptions\n occurred. [#2756](https://github.com/pybind/pybind11/pull/2756)\n- Added a Valgrind build, checking for leaks and memory-related UB,\n to CI. [#2746](https://github.com/pybind/pybind11/pull/2746)\n\nCompiler support:\n\n- Intel compiler was not activating C++14 support due to a broken\n define. [#2679](https://github.com/pybind/pybind11/pull/2679)\n- Support ICC and NVIDIA HPC SDK in C++17 mode.\n [#2729](https://github.com/pybind/pybind11/pull/2729)\n- Support Intel OneAPI compiler (ICC 20.2) and add to CI.\n [#2573](https://github.com/pybind/pybind11/pull/2573)\n\n## v2.6.1 (Nov 11, 2020)\n\n- `py::exec`, `py::eval`, and `py::eval_file` now add the builtins\n module as `\"__builtins__\"` to their `globals` argument, better\n matching `exec` and `eval` in pure Python.\n [#2616](https://github.com/pybind/pybind11/pull/2616)\n- `setup_helpers` will no longer set a minimum macOS version higher than\n the current version.\n [#2622](https://github.com/pybind/pybind11/pull/2622)\n- Allow deleting static properties.\n [#2629](https://github.com/pybind/pybind11/pull/2629)\n- Seal a leak in `def_buffer`, cleaning up the `capture` object after\n the `class_` object goes out of scope.\n [#2634](https://github.com/pybind/pybind11/pull/2634)\n- `pybind11_INCLUDE_DIRS` was incorrect, potentially causing a\n regression if it was expected to include `PYTHON_INCLUDE_DIRS` (please\n use targets instead).\n [#2636](https://github.com/pybind/pybind11/pull/2636)\n- Added parameter names to the `py::enum_` constructor and methods,\n avoiding `arg0` in the generated docstrings.\n [#2637](https://github.com/pybind/pybind11/pull/2637)\n- Added `needs_recompile` optional function to the `ParallelCompiler`\n helper, to allow a recompile to be skipped based on a user-defined\n function. [#2643](https://github.com/pybind/pybind11/pull/2643)\n\n## v2.6.0 (Oct 21, 2020)\n\nSee `upgrade-guide-2.6` for help upgrading to the new version.\n\nNew features:\n\n- Keyword-only arguments supported in Python 2 or 3 with\n `py::kw_only()`.\n [#2100](https://github.com/pybind/pybind11/pull/2100)\n- Positional-only arguments supported in Python 2 or 3 with\n `py::pos_only()`.\n [#2459](https://github.com/pybind/pybind11/pull/2459)\n- `py::is_final()` class modifier to block subclassing (CPython only).\n [#2151](https://github.com/pybind/pybind11/pull/2151)\n- Added `py::prepend()`, allowing a function to be placed at the\n beginning of the overload chain.\n [#1131](https://github.com/pybind/pybind11/pull/1131)\n- Access to the type object now provided with `py::type::of()` and\n `py::type::of(h)`.\n [#2364](https://github.com/pybind/pybind11/pull/2364)\n- Perfect forwarding support for methods.\n [#2048](https://github.com/pybind/pybind11/pull/2048)\n- Added `py::error_already_set::discard_as_unraisable()`.\n [#2372](https://github.com/pybind/pybind11/pull/2372)\n- `py::hash` is now public.\n [#2217](https://github.com/pybind/pybind11/pull/2217)\n- `py::class_` is now supported. Note that writing to one\n data member of the union and reading another (type punning) is UB in\n C++. Thus pybind11-bound enums should never be used for such\n conversions. [#2320](https://github.com/pybind/pybind11/pull/2320).\n- Classes now check local scope when registering members, allowing a\n subclass to have a member with the same name as a parent (such as an\n enum). [#2335](https://github.com/pybind/pybind11/pull/2335)\n\nCode correctness features:\n\n- Error now thrown when `__init__` is forgotten on subclasses.\n [#2152](https://github.com/pybind/pybind11/pull/2152)\n- Throw error if conversion to a pybind11 type if the Python object\n isn't a valid instance of that type, such as `py::bytes(o)` when\n `py::object o` isn't a bytes instance.\n [#2349](https://github.com/pybind/pybind11/pull/2349)\n- Throw if conversion to `str` fails.\n [#2477](https://github.com/pybind/pybind11/pull/2477)\n\nAPI changes:\n\n- `py::module` was renamed `py::module_` to avoid issues with C++20 when\n used unqualified, but an alias `py::module` is provided for backward\n compatibility. [#2489](https://github.com/pybind/pybind11/pull/2489)\n- Public constructors for `py::module_` have been deprecated; please use\n `pybind11::module_::create_extension_module` if you were using the\n public constructor (fairly rare after `PYBIND11_MODULE` was\n introduced). [#2552](https://github.com/pybind/pybind11/pull/2552)\n- `PYBIND11_OVERLOAD*` macros and `get_overload` function replaced by\n correctly-named `PYBIND11_OVERRIDE*` and `get_override`, fixing\n inconsistencies in the presence of a closing `;` in these macros.\n `get_type_overload` is deprecated.\n [#2325](https://github.com/pybind/pybind11/pull/2325)\n\nPackaging / building improvements:\n\n- The Python package was reworked to be more powerful and useful.\n [#2433](https://github.com/pybind/pybind11/pull/2433)\n - `build-setuptools` is easier thanks to a new\n `pybind11.setup_helpers` module, which provides utilities to use\n setuptools with pybind11. It can be used via PEP 518,\n `setup_requires`, or by directly importing or copying\n `setup_helpers.py` into your project.\n - CMake configuration files are now included in the Python package.\n Use `pybind11.get_cmake_dir()` or `python -m pybind11 --cmakedir` to\n get the directory with the CMake configuration files, or include the\n site-packages location in your `CMAKE_MODULE_PATH`. Or you can use\n the new `pybind11[global]` extra when you install `pybind11`, which\n installs the CMake files and headers into your base environment in\n the standard location.\n - `pybind11-config` is another way to write `python -m pybind11` if\n you have your PATH set up.\n - Added external typing support to the helper module, code from\n `import pybind11` can now be type checked.\n [#2588](https://github.com/pybind/pybind11/pull/2588)\n- Minimum CMake required increased to 3.4.\n [#2338](https://github.com/pybind/pybind11/pull/2338) and\n [#2370](https://github.com/pybind/pybind11/pull/2370)\n - Full integration with CMake's C++ standard system and compile\n features replaces `PYBIND11_CPP_STANDARD`.\n - Generated config file is now portable to different\n Python/compiler/CMake versions.\n - Virtual environments prioritized if `PYTHON_EXECUTABLE` is not set\n (`venv`, `virtualenv`, and `conda`) (similar to the new FindPython\n mode).\n - Other CMake features now natively supported, like\n `CMAKE_INTERPROCEDURAL_OPTIMIZATION`,\n `set(CMAKE_CXX_VISIBILITY_PRESET hidden)`.\n - `CUDA` as a language is now supported.\n - Helper functions `pybind11_strip`, `pybind11_extension`,\n `pybind11_find_import` added, see `cmake/index`.\n - Optional `find-python-mode` and `nopython-mode` with CMake.\n [#2370](https://github.com/pybind/pybind11/pull/2370)\n- Uninstall target added.\n [#2265](https://github.com/pybind/pybind11/pull/2265) and\n [#2346](https://github.com/pybind/pybind11/pull/2346)\n- `pybind11_add_module()` now accepts an optional `OPT_SIZE` flag that\n switches the binding target to size-based optimization if the global\n build type can not always be fixed to `MinSizeRel` (except in debug\n mode, where optimizations remain disabled). `MinSizeRel` or this flag\n reduces binary size quite substantially (~25% on some platforms).\n [#2463](https://github.com/pybind/pybind11/pull/2463)\n\nSmaller or developer focused features and fixes:\n\n- Moved `mkdoc.py` to a new repo,\n [pybind11-mkdoc](https://github.com/pybind/pybind11-mkdoc). There are\n no longer submodules in the main repo.\n- `py::memoryview` segfault fix and update, with new\n `py::memoryview::from_memory` in Python 3, and documentation.\n [#2223](https://github.com/pybind/pybind11/pull/2223)\n- Fix for `buffer_info` on Python 2.\n [#2503](https://github.com/pybind/pybind11/pull/2503)\n- If `__eq__` defined but not `__hash__`, `__hash__` is now set to\n `None`. [#2291](https://github.com/pybind/pybind11/pull/2291)\n- `py::ellipsis` now also works on Python 2.\n [#2360](https://github.com/pybind/pybind11/pull/2360)\n- Pointer to `std::tuple` & `std::pair` supported in cast.\n [#2334](https://github.com/pybind/pybind11/pull/2334)\n- Small fixes in NumPy support. `py::array` now uses `py::ssize_t` as\n first argument type.\n [#2293](https://github.com/pybind/pybind11/pull/2293)\n- Added missing signature for `py::array`.\n [#2363](https://github.com/pybind/pybind11/pull/2363)\n- `unchecked_mutable_reference` has access to operator `()` and `[]`\n when const. [#2514](https://github.com/pybind/pybind11/pull/2514)\n- `py::vectorize` is now supported on functions that return void.\n [#1969](https://github.com/pybind/pybind11/pull/1969)\n- `py::capsule` supports `get_pointer` and `set_pointer`.\n [#1131](https://github.com/pybind/pybind11/pull/1131)\n- Fix crash when different instances share the same pointer of the same\n type. [#2252](https://github.com/pybind/pybind11/pull/2252)\n- Fix for `py::len` not clearing Python's error state when it fails and\n throws. [#2575](https://github.com/pybind/pybind11/pull/2575)\n- Bugfixes related to more extensive testing, new GitHub Actions CI.\n [#2321](https://github.com/pybind/pybind11/pull/2321)\n- Bug in timezone issue in Eastern hemisphere midnight fixed.\n [#2438](https://github.com/pybind/pybind11/pull/2438)\n- `std::chrono::time_point` now works when the resolution is not the\n same as the system.\n [#2481](https://github.com/pybind/pybind11/pull/2481)\n- Bug fixed where `py::array_t` could accept arrays that did not match\n the requested ordering.\n [#2484](https://github.com/pybind/pybind11/pull/2484)\n- Avoid a segfault on some compilers when types are removed in Python.\n [#2564](https://github.com/pybind/pybind11/pull/2564)\n- `py::arg::none()` is now also respected when passing keyword\n arguments. [#2611](https://github.com/pybind/pybind11/pull/2611)\n- PyPy fixes, PyPy 7.3.x now supported, including PyPy3. (Known issue\n with PyPy2 and Windows\n [#2596](https://github.com/pybind/pybind11/issues/2596)).\n [#2146](https://github.com/pybind/pybind11/pull/2146)\n- CPython 3.9.0 workaround for undefined behavior (macOS segfault).\n [#2576](https://github.com/pybind/pybind11/pull/2576)\n- CPython 3.9 warning fixes.\n [#2253](https://github.com/pybind/pybind11/pull/2253)\n- Improved C++20 support, now tested in CI.\n [#2489](https://github.com/pybind/pybind11/pull/2489)\n [#2599](https://github.com/pybind/pybind11/pull/2599)\n- Improved but still incomplete debug Python interpreter support.\n [#2025](https://github.com/pybind/pybind11/pull/2025)\n- NVCC (CUDA 11) now supported and tested in CI.\n [#2461](https://github.com/pybind/pybind11/pull/2461)\n- NVIDIA PGI compilers now supported and tested in CI.\n [#2475](https://github.com/pybind/pybind11/pull/2475)\n- At least Intel 18 now explicitly required when compiling with Intel.\n [#2577](https://github.com/pybind/pybind11/pull/2577)\n- Extensive style checking in CI, with\n [pre-commit](https://pre-commit.com) support. Code modernization,\n checked by clang-tidy.\n- Expanded docs, including new main page, new installing section, and\n CMake helpers page, along with over a dozen new sections on existing\n pages.\n- In GitHub, new docs for contributing and new issue templates.\n\n## v2.5.0 (Mar 31, 2020)\n\n- Use C++17 fold expressions in type casters, if available. This can\n improve performance during overload resolution when functions have\n multiple arguments.\n [#2043](https://github.com/pybind/pybind11/pull/2043).\n- Changed include directory resolution in `pybind11/__init__.py` and\n installation in `setup.py`. This fixes a number of open issues where\n pybind11 headers could not be found in certain environments.\n [#1995](https://github.com/pybind/pybind11/pull/1995).\n- C++20 `char8_t` and `u8string` support.\n [#2026](https://github.com/pybind/pybind11/pull/2026).\n- CMake: search for Python 3.9.\n [bb9c91](https://github.com/pybind/pybind11/commit/bb9c91).\n- Fixes for MSYS-based build environments.\n [#2087](https://github.com/pybind/pybind11/pull/2087),\n [#2053](https://github.com/pybind/pybind11/pull/2053).\n- STL bindings for `std::vector<...>::clear`.\n [#2074](https://github.com/pybind/pybind11/pull/2074).\n- Read-only flag for `py::buffer`.\n [#1466](https://github.com/pybind/pybind11/pull/1466).\n- Exception handling during module initialization.\n [bf2b031](https://github.com/pybind/pybind11/commit/bf2b031).\n- Support linking against a CPython debug build.\n [#2025](https://github.com/pybind/pybind11/pull/2025).\n- Fixed issues involving the availability and use of aligned `new` and\n `delete`. [#1988](https://github.com/pybind/pybind11/pull/1988),\n [759221](https://github.com/pybind/pybind11/commit/759221).\n- Fixed a resource leak upon interpreter shutdown.\n [#2020](https://github.com/pybind/pybind11/pull/2020).\n- Fixed error handling in the boolean caster.\n [#1976](https://github.com/pybind/pybind11/pull/1976).\n\n## v2.4.3 (Oct 15, 2019)\n\n- Adapt pybind11 to a C API convention change in Python 3.8.\n [#1950](https://github.com/pybind/pybind11/pull/1950).\n\n## v2.4.2 (Sep 21, 2019)\n\n- Replaced usage of a C++14 only construct.\n [#1929](https://github.com/pybind/pybind11/pull/1929).\n- Made an ifdef future-proof for Python \\>= 4.\n [f3109d](https://github.com/pybind/pybind11/commit/f3109d).\n\n## v2.4.1 (Sep 20, 2019)\n\n- Fixed a problem involving implicit conversion from enumerations to\n integers on Python 3.8.\n [#1780](https://github.com/pybind/pybind11/pull/1780).\n\n## v2.4.0 (Sep 19, 2019)\n\n- Try harder to keep pybind11-internal data structures separate when\n there are potential ABI incompatibilities. Fixes crashes that occurred\n when loading multiple pybind11 extensions that were e.g. compiled by\n GCC (libstdc++) and Clang (libc++).\n [#1588](https://github.com/pybind/pybind11/pull/1588) and\n [c9f5a](https://github.com/pybind/pybind11/commit/c9f5a).\n- Added support for `__await__`, `__aiter__`, and `__anext__` protocols.\n [#1842](https://github.com/pybind/pybind11/pull/1842).\n- `pybind11_add_module()`: don't strip symbols when compiling in\n `RelWithDebInfo` mode.\n [#1980](https://github.com/pybind/pybind11/pull/1980).\n- `enum_`: Reproduce Python behavior when comparing against invalid\n values (e.g. `None`, strings, etc.). Add back support for\n `__invert__()`.\n [#1912](https://github.com/pybind/pybind11/pull/1912),\n [#1907](https://github.com/pybind/pybind11/pull/1907).\n- List insertion operation for `py::list`. Added `.empty()` to all\n collection types. Added `py::set::contains()` and\n `py::dict::contains()`.\n [#1887](https://github.com/pybind/pybind11/pull/1887),\n [#1884](https://github.com/pybind/pybind11/pull/1884),\n [#1888](https://github.com/pybind/pybind11/pull/1888).\n- `py::details::overload_cast_impl` is available in C++11 mode, can be\n used like `overload_cast` with an additional set of parentheses.\n [#1581](https://github.com/pybind/pybind11/pull/1581).\n- Fixed `get_include()` on Conda.\n [#1877](https://github.com/pybind/pybind11/pull/1877).\n- `stl_bind.h`: negative indexing support.\n [#1882](https://github.com/pybind/pybind11/pull/1882).\n- Minor CMake fix to add MinGW compatibility.\n [#1851](https://github.com/pybind/pybind11/pull/1851).\n- GIL-related fixes.\n [#1836](https://github.com/pybind/pybind11/pull/1836),\n [8b90b](https://github.com/pybind/pybind11/commit/8b90b).\n- Other very minor/subtle fixes and improvements.\n [#1329](https://github.com/pybind/pybind11/pull/1329),\n [#1910](https://github.com/pybind/pybind11/pull/1910),\n [#1863](https://github.com/pybind/pybind11/pull/1863),\n [#1847](https://github.com/pybind/pybind11/pull/1847),\n [#1890](https://github.com/pybind/pybind11/pull/1890),\n [#1860](https://github.com/pybind/pybind11/pull/1860),\n [#1848](https://github.com/pybind/pybind11/pull/1848),\n [#1821](https://github.com/pybind/pybind11/pull/1821),\n [#1837](https://github.com/pybind/pybind11/pull/1837),\n [#1833](https://github.com/pybind/pybind11/pull/1833),\n [#1748](https://github.com/pybind/pybind11/pull/1748),\n [#1852](https://github.com/pybind/pybind11/pull/1852).\n\n## v2.3.0 (June 11, 2019)\n\n- Significantly reduced module binary size (10-20%) when compiled in\n C++11 mode with GCC/Clang, or in any mode with MSVC. Function\n signatures are now always precomputed at compile time (this was\n previously only available in C++14 mode for non-MSVC compilers).\n [#934](https://github.com/pybind/pybind11/pull/934).\n\n- Add basic support for tag-based static polymorphism, where classes\n provide a method to returns the desired type of an instance.\n [#1326](https://github.com/pybind/pybind11/pull/1326).\n\n- Python type wrappers (`py::handle`, `py::object`, etc.) now support\n map Python's number protocol onto C++ arithmetic operators such as\n `operator+`, `operator/=`, etc.\n [#1511](https://github.com/pybind/pybind11/pull/1511).\n\n- A number of improvements related to enumerations:\n\n > 1. The `enum_` implementation was rewritten from scratch to reduce\n > code bloat. Rather than instantiating a full implementation for\n > each enumeration, most code is now contained in a generic base\n > class. [#1511](https://github.com/pybind/pybind11/pull/1511).\n > 2. The `value()` method of `py::enum_` now accepts an optional\n > docstring that will be shown in the documentation of the\n > associated enumeration.\n > [#1160](https://github.com/pybind/pybind11/pull/1160).\n > 3. check for already existing enum value and throw an error if\n > present. [#1453](https://github.com/pybind/pybind11/pull/1453).\n\n- Support for over-aligned type allocation via C++17's aligned `new`\n statement. [#1582](https://github.com/pybind/pybind11/pull/1582).\n\n- Added `py::ellipsis()` method for slicing of multidimensional NumPy\n arrays [#1502](https://github.com/pybind/pybind11/pull/1502).\n\n- Numerous Improvements to the `mkdoc.py` script for extracting\n documentation from C++ header files.\n [#1788](https://github.com/pybind/pybind11/pull/1788).\n\n- `pybind11_add_module()`: allow including Python as a `SYSTEM` include\n path. [#1416](https://github.com/pybind/pybind11/pull/1416).\n\n- `pybind11/stl.h` does not convert strings to `vector` anymore.\n [#1258](https://github.com/pybind/pybind11/issues/1258).\n\n- Mark static methods as such to fix auto-generated Sphinx\n documentation. [#1732](https://github.com/pybind/pybind11/pull/1732).\n\n- Re-throw forced unwind exceptions (e.g. during pthread termination).\n [#1208](https://github.com/pybind/pybind11/pull/1208).\n\n- Added `__contains__` method to the bindings of maps (`std::map`,\n `std::unordered_map`).\n [#1767](https://github.com/pybind/pybind11/pull/1767).\n\n- Improvements to `gil_scoped_acquire`.\n [#1211](https://github.com/pybind/pybind11/pull/1211).\n\n- Type caster support for `std::deque`.\n [#1609](https://github.com/pybind/pybind11/pull/1609).\n\n- Support for `std::unique_ptr` holders, whose deleters differ between a\n base and derived class.\n [#1353](https://github.com/pybind/pybind11/pull/1353).\n\n- Construction of STL array/vector-like data structures from iterators.\n Added an `extend()` operation.\n [#1709](https://github.com/pybind/pybind11/pull/1709),\n\n- CMake build system improvements for projects that include non-C++\n files (e.g. plain C, CUDA) in `pybind11_add_module` et al.\n [#1678](https://github.com/pybind/pybind11/pull/1678).\n\n- Fixed asynchronous invocation and deallocation of Python functions\n wrapped in `std::function`.\n [#1595](https://github.com/pybind/pybind11/pull/1595).\n\n- Fixes regarding return value policy propagation in STL type casters.\n [#1603](https://github.com/pybind/pybind11/pull/1603).\n\n- Fixed scoped enum comparisons.\n [#1571](https://github.com/pybind/pybind11/pull/1571).\n\n- Fixed iostream redirection for code that releases the GIL.\n [#1368](https://github.com/pybind/pybind11/pull/1368),\n\n- A number of CI-related fixes.\n [#1757](https://github.com/pybind/pybind11/pull/1757),\n [#1744](https://github.com/pybind/pybind11/pull/1744),\n [#1670](https://github.com/pybind/pybind11/pull/1670).\n\n## v2.2.4 (September 11, 2018)\n\n- Use new Python 3.7 Thread Specific Storage (TSS) implementation if\n available. [#1454](https://github.com/pybind/pybind11/pull/1454),\n [#1517](https://github.com/pybind/pybind11/pull/1517).\n- Fixes for newer MSVC versions and C++17 mode.\n [#1347](https://github.com/pybind/pybind11/pull/1347),\n [#1462](https://github.com/pybind/pybind11/pull/1462).\n- Propagate return value policies to type-specific casters when casting\n STL containers.\n [#1455](https://github.com/pybind/pybind11/pull/1455).\n- Allow ostream-redirection of more than 1024 characters.\n [#1479](https://github.com/pybind/pybind11/pull/1479).\n- Set `Py_DEBUG` define when compiling against a debug Python build.\n [#1438](https://github.com/pybind/pybind11/pull/1438).\n- Untangle integer logic in number type caster to work for custom types\n that may only be castable to a restricted set of builtin types.\n [#1442](https://github.com/pybind/pybind11/pull/1442).\n- CMake build system: Remember Python version in cache file.\n [#1434](https://github.com/pybind/pybind11/pull/1434).\n- Fix for custom smart pointers: use `std::addressof` to obtain holder\n address instead of `operator&`.\n [#1435](https://github.com/pybind/pybind11/pull/1435).\n- Properly report exceptions thrown during module initialization.\n [#1362](https://github.com/pybind/pybind11/pull/1362).\n- Fixed a segmentation fault when creating empty-shaped NumPy array.\n [#1371](https://github.com/pybind/pybind11/pull/1371).\n- The version of Intel C++ compiler must be \\>= 2017, and this is now\n checked by the header files.\n [#1363](https://github.com/pybind/pybind11/pull/1363).\n- A few minor typo fixes and improvements to the test suite, and patches\n that silence compiler warnings.\n- Vectors now support construction from generators, as well as\n `extend()` from a list or generator.\n [#1496](https://github.com/pybind/pybind11/pull/1496).\n\n## v2.2.3 (April 29, 2018)\n\n- The pybind11 header location detection was replaced by a new\n implementation that no longer depends on `pip` internals (the recently\n released `pip` 10 has restricted access to this API).\n [#1190](https://github.com/pybind/pybind11/pull/1190).\n- Small adjustment to an implementation detail to work around a compiler\n segmentation fault in Clang 3.3/3.4.\n [#1350](https://github.com/pybind/pybind11/pull/1350).\n- The minimal supported version of the Intel compiler was \\>= 17.0 since\n pybind11 v2.1. This check is now explicit, and a compile-time error is\n raised if the compiler meet the requirement.\n [#1363](https://github.com/pybind/pybind11/pull/1363).\n- Fixed an endianness-related fault in the test suite.\n [#1287](https://github.com/pybind/pybind11/pull/1287).\n\n## v2.2.2 (February 7, 2018)\n\n- Fixed a segfault when combining embedded interpreter\n shutdown/reinitialization with external loaded pybind11 modules.\n [#1092](https://github.com/pybind/pybind11/pull/1092).\n- Eigen support: fixed a bug where Nx1/1xN numpy inputs couldn't be\n passed as arguments to Eigen vectors (which for Eigen are simply\n compile-time fixed Nx1/1xN matrices).\n [#1106](https://github.com/pybind/pybind11/pull/1106).\n- Clarified to license by moving the licensing of contributions from\n `LICENSE` into `CONTRIBUTING.md`: the licensing of contributions is\n not actually part of the software license as distributed. This isn't\n meant to be a substantial change in the licensing of the project, but\n addresses concerns that the clause made the license non-standard.\n [#1109](https://github.com/pybind/pybind11/issues/1109).\n- Fixed a regression introduced in 2.1 that broke binding functions with\n lvalue character literal arguments.\n [#1128](https://github.com/pybind/pybind11/pull/1128).\n- MSVC: fix for compilation failures under /permissive-, and added the\n flag to the appveyor test suite.\n [#1155](https://github.com/pybind/pybind11/pull/1155).\n- Fixed `__qualname__` generation, and in turn, fixes how class names\n (especially nested class names) are shown in generated docstrings.\n [#1171](https://github.com/pybind/pybind11/pull/1171).\n- Updated the FAQ with a suggested project citation reference.\n [#1189](https://github.com/pybind/pybind11/pull/1189).\n- Added fixes for deprecation warnings when compiled under C++17 with\n `-Wdeprecated` turned on, and add `-Wdeprecated` to the test suite\n compilation flags.\n [#1191](https://github.com/pybind/pybind11/pull/1191).\n- Fixed outdated PyPI URLs in `setup.py`.\n [#1213](https://github.com/pybind/pybind11/pull/1213).\n- Fixed a refcount leak for arguments that end up in a `py::args`\n argument for functions with both fixed positional and `py::args`\n arguments. [#1216](https://github.com/pybind/pybind11/pull/1216).\n- Fixed a potential segfault resulting from possible premature\n destruction of `py::args`/`py::kwargs` arguments with overloaded\n functions. [#1223](https://github.com/pybind/pybind11/pull/1223).\n- Fixed `del map[item]` for a `stl_bind.h` bound stl map.\n [#1229](https://github.com/pybind/pybind11/pull/1229).\n- Fixed a regression from v2.1.x where the aggregate initialization\n could unintentionally end up at a constructor taking a templated\n `std::initializer_list` argument.\n [#1249](https://github.com/pybind/pybind11/pull/1249).\n- Fixed an issue where calling a function with a keep_alive policy on\n the same nurse/patient pair would cause the internal patient storage\n to needlessly grow (unboundedly, if the nurse is long-lived).\n [#1251](https://github.com/pybind/pybind11/issues/1251).\n- Various other minor fixes.\n\n## v2.2.1 (September 14, 2017)\n\n- Added `py::module_::reload()` member function for reloading a module.\n [#1040](https://github.com/pybind/pybind11/pull/1040).\n- Fixed a reference leak in the number converter.\n [#1078](https://github.com/pybind/pybind11/pull/1078).\n- Fixed compilation with Clang on host GCC \\< 5 (old libstdc++ which\n isn't fully C++11 compliant).\n [#1062](https://github.com/pybind/pybind11/pull/1062).\n- Fixed a regression where the automatic `std::vector` caster\n would fail to compile. The same fix also applies to any container\n which returns element proxies instead of references.\n [#1053](https://github.com/pybind/pybind11/pull/1053).\n- Fixed a regression where the `py::keep_alive` policy could not be\n applied to constructors.\n [#1065](https://github.com/pybind/pybind11/pull/1065).\n- Fixed a nullptr dereference when loading a `py::module_local` type\n that's only registered in an external module.\n [#1058](https://github.com/pybind/pybind11/pull/1058).\n- Fixed implicit conversion of accessors to types derived from\n `py::object`. [#1076](https://github.com/pybind/pybind11/pull/1076).\n- The `name` in `PYBIND11_MODULE(name, variable)` can now be a macro.\n [#1082](https://github.com/pybind/pybind11/pull/1082).\n- Relaxed overly strict `py::pickle()` check for matching get and set\n types. [#1064](https://github.com/pybind/pybind11/pull/1064).\n- Conversion errors now try to be more informative when it's likely that\n a missing header is the cause (e.g. forgetting ``).\n [#1077](https://github.com/pybind/pybind11/pull/1077).\n\n## v2.2.0 (August 31, 2017)\n\n- Support for embedding the Python interpreter. See the\n `documentation page ` for a full overview of the\n new features. [#774](https://github.com/pybind/pybind11/pull/774),\n [#889](https://github.com/pybind/pybind11/pull/889),\n [#892](https://github.com/pybind/pybind11/pull/892),\n [#920](https://github.com/pybind/pybind11/pull/920).\n\n ```cpp\n #include \n namespace py = pybind11;\n\n int main() {\n py::scoped_interpreter guard{}; // start the interpreter and keep it alive\n\n py::print(\"Hello, World!\"); // use the Python API\n }\n ```\n\n- Support for inheriting from multiple C++ bases in Python.\n [#693](https://github.com/pybind/pybind11/pull/693).\n\n ```python\n from cpp_module import CppBase1, CppBase2\n\n\n class PyDerived(CppBase1, CppBase2):\n def __init__(self):\n CppBase1.__init__(self) # C++ bases must be initialized explicitly\n CppBase2.__init__(self)\n ```\n\n- `PYBIND11_MODULE` is now the preferred way to create module entry\n points. `PYBIND11_PLUGIN` is deprecated. See `macros` for details.\n [#879](https://github.com/pybind/pybind11/pull/879).\n\n ```cpp\n // new\n PYBIND11_MODULE(example, m) {\n m.def(\"add\", [](int a, int b) { return a + b; });\n }\n\n // old\n PYBIND11_PLUGIN(example) {\n py::module m(\"example\");\n m.def(\"add\", [](int a, int b) { return a + b; });\n return m.ptr();\n }\n ```\n\n- pybind11's headers and build system now more strictly enforce hidden\n symbol visibility for extension modules. This should be seamless for\n most users, but see the `upgrade` if you use a custom build system.\n [#995](https://github.com/pybind/pybind11/pull/995).\n\n- Support for `py::module_local` types which allow multiple modules to\n export the same C++ types without conflicts. This is useful for opaque\n types like `std::vector`. `py::bind_vector` and `py::bind_map`\n now default to `py::module_local` if their elements are builtins or\n local types. See `module_local` for details.\n [#949](https://github.com/pybind/pybind11/pull/949),\n [#981](https://github.com/pybind/pybind11/pull/981),\n [#995](https://github.com/pybind/pybind11/pull/995),\n [#997](https://github.com/pybind/pybind11/pull/997).\n\n- Custom constructors can now be added very easily using lambdas or\n factory functions which return a class instance by value, pointer or\n holder. This supersedes the old placement-new `__init__` technique.\n See `custom_constructors` for details.\n [#805](https://github.com/pybind/pybind11/pull/805),\n [#1014](https://github.com/pybind/pybind11/pull/1014).\n\n ```cpp\n struct Example {\n Example(std::string);\n };\n\n py::class_(m, \"Example\")\n .def(py::init()) // existing constructor\n .def(py::init([](int n) { // custom constructor\n return std::make_unique(std::to_string(n));\n }));\n ```\n\n- Similarly to custom constructors, pickling support functions are now\n bound using the `py::pickle()` adaptor which improves type safety. See\n the `upgrade` and `pickling` for details.\n [#1038](https://github.com/pybind/pybind11/pull/1038).\n\n- Builtin support for converting C++17 standard library types and\n general conversion improvements:\n\n 1. C++17 `std::variant` is supported right out of the box. C++11/14\n equivalents (e.g. `boost::variant`) can also be added with a\n simple user-defined specialization. See `cpp17_container_casters`\n for details. [#811](https://github.com/pybind/pybind11/pull/811),\n [#845](https://github.com/pybind/pybind11/pull/845),\n [#989](https://github.com/pybind/pybind11/pull/989).\n 2. Out-of-the-box support for C++17 `std::string_view`.\n [#906](https://github.com/pybind/pybind11/pull/906).\n 3. Improved compatibility of the builtin `optional` converter.\n [#874](https://github.com/pybind/pybind11/pull/874).\n 4. The `bool` converter now accepts `numpy.bool_` and types which\n define `__bool__` (Python 3.x) or `__nonzero__` (Python 2.7).\n [#925](https://github.com/pybind/pybind11/pull/925).\n 5. C++-to-Python casters are now more efficient and move elements out\n of rvalue containers whenever possible.\n [#851](https://github.com/pybind/pybind11/pull/851),\n [#936](https://github.com/pybind/pybind11/pull/936),\n [#938](https://github.com/pybind/pybind11/pull/938).\n 6. Fixed `bytes` to `std::string/char*` conversion on Python 3.\n [#817](https://github.com/pybind/pybind11/pull/817).\n 7. Fixed lifetime of temporary C++ objects created in Python-to-C++\n conversions. [#924](https://github.com/pybind/pybind11/pull/924).\n\n- Scope guard call policy for RAII types, e.g.\n `py::call_guard()`,\n `py::call_guard()`. See `call_policies`\n for details. [#740](https://github.com/pybind/pybind11/pull/740).\n\n- Utility for redirecting C++ streams to Python (e.g. `std::cout` -\\>\n `sys.stdout`). Scope guard `py::scoped_ostream_redirect` in C++ and a\n context manager in Python. See `ostream_redirect`.\n [#1009](https://github.com/pybind/pybind11/pull/1009).\n\n- Improved handling of types and exceptions across module boundaries.\n [#915](https://github.com/pybind/pybind11/pull/915),\n [#951](https://github.com/pybind/pybind11/pull/951),\n [#995](https://github.com/pybind/pybind11/pull/995).\n\n- Fixed destruction order of `py::keep_alive` nurse/patient objects in\n reference cycles.\n [#856](https://github.com/pybind/pybind11/pull/856).\n\n- NumPy and buffer protocol related improvements:\n\n 1. Support for negative strides in Python buffer objects/numpy\n arrays. This required changing integers from unsigned to signed\n for the related C++ APIs. Note: If you have compiler warnings\n enabled, you may notice some new conversion warnings after\n upgrading. These can be resolved with `static_cast`.\n [#782](https://github.com/pybind/pybind11/pull/782).\n 2. Support `std::complex` and arrays inside `PYBIND11_NUMPY_DTYPE`.\n [#831](https://github.com/pybind/pybind11/pull/831),\n [#832](https://github.com/pybind/pybind11/pull/832).\n 3. Support for constructing `py::buffer_info` and `py::arrays` using\n arbitrary containers or iterators instead of requiring a\n `std::vector`.\n [#788](https://github.com/pybind/pybind11/pull/788),\n [#822](https://github.com/pybind/pybind11/pull/822),\n [#860](https://github.com/pybind/pybind11/pull/860).\n 4. Explicitly check numpy version and require \\>= 1.7.0.\n [#819](https://github.com/pybind/pybind11/pull/819).\n\n- Support for allowing/prohibiting `None` for specific arguments and\n improved `None` overload resolution order. See `none_arguments` for\n details. [#843](https://github.com/pybind/pybind11/pull/843).\n [#859](https://github.com/pybind/pybind11/pull/859).\n\n- Added `py::exec()` as a shortcut for `py::eval()`\n and support for C++11 raw string literals as input. See `eval`.\n [#766](https://github.com/pybind/pybind11/pull/766),\n [#827](https://github.com/pybind/pybind11/pull/827).\n\n- `py::vectorize()` ignores non-vectorizable arguments and supports\n member functions.\n [#762](https://github.com/pybind/pybind11/pull/762).\n\n- Support for bound methods as callbacks (`pybind11/functional.h`).\n [#815](https://github.com/pybind/pybind11/pull/815).\n\n- Allow aliasing pybind11 methods: `cls.attr(\"foo\") = cls.attr(\"bar\")`.\n [#802](https://github.com/pybind/pybind11/pull/802).\n\n- Don't allow mixed static/non-static overloads.\n [#804](https://github.com/pybind/pybind11/pull/804).\n\n- Fixed overriding static properties in derived classes.\n [#784](https://github.com/pybind/pybind11/pull/784).\n\n- Added support for write only properties.\n [#1144](https://github.com/pybind/pybind11/pull/1144).\n\n- Improved deduction of member functions of a derived class when its\n bases aren't registered with pybind11.\n [#855](https://github.com/pybind/pybind11/pull/855).\n\n ```cpp\n struct Base {\n int foo() { return 42; }\n }\n\n struct Derived : Base {}\n\n // Now works, but previously required also binding `Base`\n py::class_(m, \"Derived\")\n .def(\"foo\", &Derived::foo); // function is actually from `Base`\n ```\n\n- The implementation of `py::init<>` now uses C++11 brace initialization\n syntax to construct instances, which permits binding implicit\n constructors of aggregate types.\n [#1015](https://github.com/pybind/pybind11/pull/1015).\n\n > ```cpp\n > struct Aggregate {\n > int a;\n > std::string b;\n > };\n >\n > py::class_(m, \"Aggregate\")\n > .def(py::init());\n > ```\n\n- Fixed issues with multiple inheritance with offset base/derived\n pointers. [#812](https://github.com/pybind/pybind11/pull/812),\n [#866](https://github.com/pybind/pybind11/pull/866),\n [#960](https://github.com/pybind/pybind11/pull/960).\n\n- Fixed reference leak of type objects.\n [#1030](https://github.com/pybind/pybind11/pull/1030).\n\n- Improved support for the `/std:c++14` and `/std:c++latest` modes on\n MSVC 2017. [#841](https://github.com/pybind/pybind11/pull/841),\n [#999](https://github.com/pybind/pybind11/pull/999).\n\n- Fixed detection of private operator new on MSVC.\n [#893](https://github.com/pybind/pybind11/pull/893),\n [#918](https://github.com/pybind/pybind11/pull/918).\n\n- Intel C++ compiler compatibility fixes.\n [#937](https://github.com/pybind/pybind11/pull/937).\n\n- Fixed implicit conversion of `py::enum_` to integer types on Python\n 2.7. [#821](https://github.com/pybind/pybind11/pull/821).\n\n- Added `py::hash` to fetch the hash value of Python objects, and\n `.def(hash(py::self))` to provide the C++ `std::hash` as the Python\n `__hash__` method.\n [#1034](https://github.com/pybind/pybind11/pull/1034).\n\n- Fixed `__truediv__` on Python 2 and `__itruediv__` on Python 3.\n [#867](https://github.com/pybind/pybind11/pull/867).\n\n- `py::capsule` objects now support the `name` attribute. This is useful\n for interfacing with `scipy.LowLevelCallable`.\n [#902](https://github.com/pybind/pybind11/pull/902).\n\n- Fixed `py::make_iterator`'s `__next__()` for past-the-end calls.\n [#897](https://github.com/pybind/pybind11/pull/897).\n\n- Added `error_already_set::matches()` for checking Python exceptions.\n [#772](https://github.com/pybind/pybind11/pull/772).\n\n- Deprecated `py::error_already_set::clear()`. It's no longer needed\n following a simplification of the `py::error_already_set` class.\n [#954](https://github.com/pybind/pybind11/pull/954).\n\n- Deprecated `py::handle::operator==()` in favor of `py::handle::is()`\n [#825](https://github.com/pybind/pybind11/pull/825).\n\n- Deprecated `py::object::borrowed`/`py::object::stolen`. Use\n `py::object::borrowed_t{}`/`py::object::stolen_t{}` instead.\n [#771](https://github.com/pybind/pybind11/pull/771).\n\n- Changed internal data structure versioning to avoid conflicts between\n modules compiled with different revisions of pybind11.\n [#1012](https://github.com/pybind/pybind11/pull/1012).\n\n- Additional compile-time and run-time error checking and more\n informative messages.\n [#786](https://github.com/pybind/pybind11/pull/786),\n [#794](https://github.com/pybind/pybind11/pull/794),\n [#803](https://github.com/pybind/pybind11/pull/803).\n\n- Various minor improvements and fixes.\n [#764](https://github.com/pybind/pybind11/pull/764),\n [#791](https://github.com/pybind/pybind11/pull/791),\n [#795](https://github.com/pybind/pybind11/pull/795),\n [#840](https://github.com/pybind/pybind11/pull/840),\n [#844](https://github.com/pybind/pybind11/pull/844),\n [#846](https://github.com/pybind/pybind11/pull/846),\n [#849](https://github.com/pybind/pybind11/pull/849),\n [#858](https://github.com/pybind/pybind11/pull/858),\n [#862](https://github.com/pybind/pybind11/pull/862),\n [#871](https://github.com/pybind/pybind11/pull/871),\n [#872](https://github.com/pybind/pybind11/pull/872),\n [#881](https://github.com/pybind/pybind11/pull/881),\n [#888](https://github.com/pybind/pybind11/pull/888),\n [#899](https://github.com/pybind/pybind11/pull/899),\n [#928](https://github.com/pybind/pybind11/pull/928),\n [#931](https://github.com/pybind/pybind11/pull/931),\n [#944](https://github.com/pybind/pybind11/pull/944),\n [#950](https://github.com/pybind/pybind11/pull/950),\n [#952](https://github.com/pybind/pybind11/pull/952),\n [#962](https://github.com/pybind/pybind11/pull/962),\n [#965](https://github.com/pybind/pybind11/pull/965),\n [#970](https://github.com/pybind/pybind11/pull/970),\n [#978](https://github.com/pybind/pybind11/pull/978),\n [#979](https://github.com/pybind/pybind11/pull/979),\n [#986](https://github.com/pybind/pybind11/pull/986),\n [#1020](https://github.com/pybind/pybind11/pull/1020),\n [#1027](https://github.com/pybind/pybind11/pull/1027),\n [#1037](https://github.com/pybind/pybind11/pull/1037).\n\n- Testing improvements.\n [#798](https://github.com/pybind/pybind11/pull/798),\n [#882](https://github.com/pybind/pybind11/pull/882),\n [#898](https://github.com/pybind/pybind11/pull/898),\n [#900](https://github.com/pybind/pybind11/pull/900),\n [#921](https://github.com/pybind/pybind11/pull/921),\n [#923](https://github.com/pybind/pybind11/pull/923),\n [#963](https://github.com/pybind/pybind11/pull/963).\n\n## v2.1.1 (April 7, 2017)\n\n- Fixed minimum version requirement for MSVC 2015u3\n [#773](https://github.com/pybind/pybind11/pull/773).\n\n## v2.1.0 (March 22, 2017)\n\n- pybind11 now performs function overload resolution in two phases. The\n first phase only considers exact type matches, while the second allows\n for implicit conversions to take place. A special `noconvert()` syntax\n can be used to completely disable implicit conversions for specific\n arguments. [#643](https://github.com/pybind/pybind11/pull/643),\n [#634](https://github.com/pybind/pybind11/pull/634),\n [#650](https://github.com/pybind/pybind11/pull/650).\n- Fixed a regression where static properties no longer worked with\n classes using multiple inheritance. The `py::metaclass` attribute is\n no longer necessary (and deprecated as of this release) when binding\n classes with static properties.\n [#679](https://github.com/pybind/pybind11/pull/679),\n- Classes bound using `pybind11` can now use custom metaclasses.\n [#679](https://github.com/pybind/pybind11/pull/679),\n- `py::args` and `py::kwargs` can now be mixed with other positional\n arguments when binding functions using pybind11.\n [#611](https://github.com/pybind/pybind11/pull/611).\n- Improved support for C++11 unicode string and character types; added\n extensive documentation regarding pybind11's string conversion\n behavior. [#624](https://github.com/pybind/pybind11/pull/624),\n [#636](https://github.com/pybind/pybind11/pull/636),\n [#715](https://github.com/pybind/pybind11/pull/715).\n- pybind11 can now avoid expensive copies when converting Eigen arrays\n to NumPy arrays (and vice versa).\n [#610](https://github.com/pybind/pybind11/pull/610).\n- The \"fast path\" in `py::vectorize` now works for any full-size group\n of C or F-contiguous arrays. The non-fast path is also faster since it\n no longer performs copies of the input arguments (except when type\n conversions are necessary).\n [#610](https://github.com/pybind/pybind11/pull/610).\n- Added fast, unchecked access to NumPy arrays via a proxy object.\n [#746](https://github.com/pybind/pybind11/pull/746).\n- Transparent support for class-specific `operator new` and\n `operator delete` implementations.\n [#755](https://github.com/pybind/pybind11/pull/755).\n- Slimmer and more efficient STL-compatible iterator interface for\n sequence types. [#662](https://github.com/pybind/pybind11/pull/662).\n- Improved custom holder type support.\n [#607](https://github.com/pybind/pybind11/pull/607).\n- `nullptr` to `None` conversion fixed in various builtin type casters.\n [#732](https://github.com/pybind/pybind11/pull/732).\n- `enum_` now exposes its members via a special `__members__` attribute.\n [#666](https://github.com/pybind/pybind11/pull/666).\n- `std::vector` bindings created using `stl_bind.h` can now optionally\n implement the buffer protocol.\n [#488](https://github.com/pybind/pybind11/pull/488).\n- Automated C++ reference documentation using doxygen and breathe.\n [#598](https://github.com/pybind/pybind11/pull/598).\n- Added minimum compiler version assertions.\n [#727](https://github.com/pybind/pybind11/pull/727).\n- Improved compatibility with C++1z.\n [#677](https://github.com/pybind/pybind11/pull/677).\n- Improved `py::capsule` API. Can be used to implement cleanup callbacks\n that are involved at module destruction time.\n [#752](https://github.com/pybind/pybind11/pull/752).\n- Various minor improvements and fixes.\n [#595](https://github.com/pybind/pybind11/pull/595),\n [#588](https://github.com/pybind/pybind11/pull/588),\n [#589](https://github.com/pybind/pybind11/pull/589),\n [#603](https://github.com/pybind/pybind11/pull/603),\n [#619](https://github.com/pybind/pybind11/pull/619),\n [#648](https://github.com/pybind/pybind11/pull/648),\n [#695](https://github.com/pybind/pybind11/pull/695),\n [#720](https://github.com/pybind/pybind11/pull/720),\n [#723](https://github.com/pybind/pybind11/pull/723),\n [#729](https://github.com/pybind/pybind11/pull/729),\n [#724](https://github.com/pybind/pybind11/pull/724),\n [#742](https://github.com/pybind/pybind11/pull/742),\n [#753](https://github.com/pybind/pybind11/pull/753).\n\n## v2.0.1 (Jan 4, 2017)\n\n- Fix pointer to reference error in type_caster on MSVC\n [#583](https://github.com/pybind/pybind11/pull/583).\n- Fixed a segmentation in the test suite due to a typo\n [cd7eac](https://github.com/pybind/pybind11/commit/cd7eac).\n\n## v2.0.0 (Jan 1, 2017)\n\n- Fixed a reference counting regression affecting types with custom\n metaclasses (introduced in v2.0.0-rc1).\n [#571](https://github.com/pybind/pybind11/pull/571).\n- Quenched a CMake policy warning.\n [#570](https://github.com/pybind/pybind11/pull/570).\n\n## v2.0.0-rc1 (Dec 23, 2016)\n\nThe pybind11 developers are excited to issue a release candidate of\npybind11 with a subsequent v2.0.0 release planned in early January next\nyear.\n\nAn incredible amount of effort by went into pybind11 over the last ~5\nmonths, leading to a release that is jam-packed with exciting new\nfeatures and numerous usability improvements. The following list links\nPRs or individual commits whenever applicable.\n\nHappy Christmas!\n\n- Support for binding C++ class hierarchies that make use of multiple\n inheritance. [#410](https://github.com/pybind/pybind11/pull/410).\n\n- PyPy support: pybind11 now supports nightly builds of PyPy and will\n interoperate with the future 5.7 release. No code changes are\n necessary, everything \"just\" works as usual. Note that we only target\n the Python 2.7 branch for now; support for 3.x will be added once its\n `cpyext` extension support catches up. A few minor features remain\n unsupported for the time being (notably dynamic attributes in custom\n types). [#527](https://github.com/pybind/pybind11/pull/527).\n\n- Significant work on the documentation -- in particular, the monolithic\n `advanced.rst` file was restructured into a easier to read\n hierarchical organization.\n [#448](https://github.com/pybind/pybind11/pull/448).\n\n- Many NumPy-related improvements:\n\n 1. Object-oriented API to access and modify NumPy `ndarray`\n instances, replicating much of the corresponding NumPy C API\n functionality.\n [#402](https://github.com/pybind/pybind11/pull/402).\n\n 2. NumPy array `dtype` array descriptors are now first-class citizens\n and are exposed via a new class `py::dtype`.\n\n 3. Structured dtypes can be registered using the\n `PYBIND11_NUMPY_DTYPE()` macro. Special `array` constructors\n accepting dtype objects were also added.\n\n One potential caveat involving this change: format descriptor\n strings should now be accessed via `format_descriptor::format()`\n (however, for compatibility purposes, the old syntax\n `format_descriptor::value` will still work for non-structured data\n types). [#308](https://github.com/pybind/pybind11/pull/308).\n\n 4. Further improvements to support structured dtypes throughout the\n system. [#472](https://github.com/pybind/pybind11/pull/472),\n [#474](https://github.com/pybind/pybind11/pull/474),\n [#459](https://github.com/pybind/pybind11/pull/459),\n [#453](https://github.com/pybind/pybind11/pull/453),\n [#452](https://github.com/pybind/pybind11/pull/452), and\n [#505](https://github.com/pybind/pybind11/pull/505).\n\n 5. Fast access operators.\n [#497](https://github.com/pybind/pybind11/pull/497).\n\n 6. Constructors for arrays whose storage is owned by another object.\n [#440](https://github.com/pybind/pybind11/pull/440).\n\n 7. Added constructors for `array` and `array_t` explicitly accepting\n shape and strides; if strides are not provided, they are deduced\n assuming C-contiguity. Also added simplified constructors for\n 1-dimensional case.\n\n 8. Added buffer/NumPy support for `char[N]` and `std::array`\n types.\n\n 9. Added `memoryview` wrapper type which is constructible from\n `buffer_info`.\n\n- Eigen: many additional conversions and support for non-contiguous\n arrays/slices. [#427](https://github.com/pybind/pybind11/pull/427),\n [#315](https://github.com/pybind/pybind11/pull/315),\n [#316](https://github.com/pybind/pybind11/pull/316),\n [#312](https://github.com/pybind/pybind11/pull/312), and\n [#267](https://github.com/pybind/pybind11/pull/267)\n\n- Incompatible changes in `class_<...>::class_()`:\n\n > 1. Declarations of types that provide access via the buffer\n > protocol must now include the `py::buffer_protocol()` annotation\n > as an argument to the `class_` constructor.\n > 2. Declarations of types that require a custom metaclass (i.e. all\n > classes which include static properties via commands such as\n > `def_readwrite_static()`) must now include the `py::metaclass()`\n > annotation as an argument to the `class_` constructor.\n >\n > These two changes were necessary to make type definitions in\n > pybind11 future-proof, and to support PyPy via its cpyext\n > mechanism. [#527](https://github.com/pybind/pybind11/pull/527).\n >\n > 3. This version of pybind11 uses a redesigned mechanism for\n > instantiating trampoline classes that are used to override\n > virtual methods from within Python. This led to the following\n > user-visible syntax change: instead of\n >\n > ```cpp\n > py::class_(\"MyClass\")\n > .alias()\n > ....\n > ```\n >\n > write\n >\n > ```cpp\n > py::class_(\"MyClass\")\n > ....\n > ```\n >\n > Importantly, both the original and the trampoline class are now\n > specified as an arguments (in arbitrary order) to the\n > `py::class_` template, and the `alias<..>()` call is gone. The\n > new scheme has zero overhead in cases when Python doesn't\n > override any functions of the underlying C++ class. [rev.\n > 86d825](https://github.com/pybind/pybind11/commit/86d825).\n\n- Added `eval` and `eval_file` functions for evaluating expressions and\n statements from a string or file. [rev.\n 0d3fc3](https://github.com/pybind/pybind11/commit/0d3fc3).\n\n- pybind11 can now create types with a modifiable dictionary.\n [#437](https://github.com/pybind/pybind11/pull/437) and\n [#444](https://github.com/pybind/pybind11/pull/444).\n\n- Support for translation of arbitrary C++ exceptions to Python\n counterparts. [#296](https://github.com/pybind/pybind11/pull/296) and\n [#273](https://github.com/pybind/pybind11/pull/273).\n\n- Report full backtraces through mixed C++/Python code, better reporting\n for import errors, fixed GIL management in exception processing.\n [#537](https://github.com/pybind/pybind11/pull/537),\n [#494](https://github.com/pybind/pybind11/pull/494), [rev.\n e72d95](https://github.com/pybind/pybind11/commit/e72d95), and [rev.\n 099d6e](https://github.com/pybind/pybind11/commit/099d6e).\n\n- Support for bit-level operations, comparisons, and serialization of\n C++ enumerations.\n [#503](https://github.com/pybind/pybind11/pull/503),\n [#508](https://github.com/pybind/pybind11/pull/508),\n [#380](https://github.com/pybind/pybind11/pull/380),\n [#309](https://github.com/pybind/pybind11/pull/309).\n [#311](https://github.com/pybind/pybind11/pull/311).\n\n- The `class_` constructor now accepts its template arguments in any\n order. [#385](https://github.com/pybind/pybind11/pull/385).\n\n- Attribute and item accessors now have a more complete interface which\n makes it possible to chain attributes as in\n `obj.attr(\"a\")[key].attr(\"b\").attr(\"method\")(1, 2, 3)`.\n [#425](https://github.com/pybind/pybind11/pull/425).\n\n- Major redesign of the default and conversion constructors in\n `pytypes.h`. [#464](https://github.com/pybind/pybind11/pull/464).\n\n- Added built-in support for `std::shared_ptr` holder type. It is no\n longer necessary to to include a declaration of the form\n `PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr)` (though\n continuing to do so won't cause an error).\n [#454](https://github.com/pybind/pybind11/pull/454).\n\n- New `py::overload_cast` casting operator to select among multiple\n possible overloads of a function. An example:\n\n > ```cpp\n > py::class_(m, \"Pet\")\n > .def(\"set\", py::overload_cast(&Pet::set), \"Set the pet's age\")\n > .def(\"set\", py::overload_cast(&Pet::set), \"Set the pet's name\");\n > ```\n\n This feature only works on C++14-capable compilers.\n [#541](https://github.com/pybind/pybind11/pull/541).\n\n- C++ types are automatically cast to Python types, e.g. when assigning\n them as an attribute. For instance, the following is now legal:\n\n > ```cpp\n > py::module m = /* ... */\n > m.attr(\"constant\") = 123;\n > ```\n\n (Previously, a `py::cast` call was necessary to avoid a compilation\n error.) [#551](https://github.com/pybind/pybind11/pull/551).\n\n- Redesigned `pytest`-based test suite.\n [#321](https://github.com/pybind/pybind11/pull/321).\n\n- Instance tracking to detect reference leaks in test suite.\n [#324](https://github.com/pybind/pybind11/pull/324)\n\n- pybind11 can now distinguish between multiple different instances that\n are located at the same memory address, but which have different\n types. [#329](https://github.com/pybind/pybind11/pull/329).\n\n- Improved logic in `move` return value policy.\n [#510](https://github.com/pybind/pybind11/pull/510),\n [#297](https://github.com/pybind/pybind11/pull/297).\n\n- Generalized unpacking API to permit calling Python functions from C++\n using notation such as\n `foo(a1, a2, *args, \"ka\"_a=1, \"kb\"_a=2, **kwargs)`.\n [#372](https://github.com/pybind/pybind11/pull/372).\n\n- `py::print()` function whose behavior matches that of the native\n Python `print()` function.\n [#372](https://github.com/pybind/pybind11/pull/372).\n\n- Added `py::dict` keyword\n constructor:`auto d = dict(\"number\"_a=42, \"name\"_a=\"World\");`.\n [#372](https://github.com/pybind/pybind11/pull/372).\n\n- Added `py::str::format()` method and `_s` literal:\n `py::str s = \"1 + 2 = {}\"_s.format(3);`.\n [#372](https://github.com/pybind/pybind11/pull/372).\n\n- Added `py::repr()` function which is equivalent to Python's builtin\n `repr()`. [#333](https://github.com/pybind/pybind11/pull/333).\n\n- Improved construction and destruction logic for holder types. It is\n now possible to reference instances with smart pointer holder types\n without constructing the holder if desired. The\n `PYBIND11_DECLARE_HOLDER_TYPE` macro now accepts an optional second\n parameter to indicate whether the holder type uses intrusive reference\n counting. [#533](https://github.com/pybind/pybind11/pull/533) and\n [#561](https://github.com/pybind/pybind11/pull/561).\n\n- Mapping a stateless C++ function to Python and back is now \"for free\"\n (i.e. no extra indirections or argument conversion overheads). [rev.\n 954b79](https://github.com/pybind/pybind11/commit/954b79).\n\n- Bindings for `std::valarray`.\n [#545](https://github.com/pybind/pybind11/pull/545).\n\n- Improved support for C++17 capable compilers.\n [#562](https://github.com/pybind/pybind11/pull/562).\n\n- Bindings for `std::optional`.\n [#475](https://github.com/pybind/pybind11/pull/475),\n [#476](https://github.com/pybind/pybind11/pull/476),\n [#479](https://github.com/pybind/pybind11/pull/479),\n [#499](https://github.com/pybind/pybind11/pull/499), and\n [#501](https://github.com/pybind/pybind11/pull/501).\n\n- `stl_bind.h`: general improvements and support for `std::map` and\n `std::unordered_map`.\n [#490](https://github.com/pybind/pybind11/pull/490),\n [#282](https://github.com/pybind/pybind11/pull/282),\n [#235](https://github.com/pybind/pybind11/pull/235).\n\n- The `std::tuple`, `std::pair`, `std::list`, and `std::vector` type\n casters now accept any Python sequence type as input. [rev.\n 107285](https://github.com/pybind/pybind11/commit/107285).\n\n- Improved CMake Python detection on multi-architecture Linux.\n [#532](https://github.com/pybind/pybind11/pull/532).\n\n- Infrastructure to selectively disable or enable parts of the\n automatically generated docstrings.\n [#486](https://github.com/pybind/pybind11/pull/486).\n\n- `reference` and `reference_internal` are now the default return value\n properties for static and non-static properties, respectively.\n [#473](https://github.com/pybind/pybind11/pull/473). (the previous\n defaults were `automatic`).\n [#473](https://github.com/pybind/pybind11/pull/473).\n\n- Support for `std::unique_ptr` with non-default deleters or no deleter\n at all (`py::nodelete`).\n [#384](https://github.com/pybind/pybind11/pull/384).\n\n- Deprecated `handle::call()` method. The new syntax to call Python\n functions is simply `handle()`. It can also be invoked explicitly via\n `handle::operator()`, where `X` is an optional return value policy.\n\n- Print more informative error messages when `make_tuple()` or `cast()`\n fail. [#262](https://github.com/pybind/pybind11/pull/262).\n\n- Creation of holder types for classes deriving from\n `std::enable_shared_from_this<>` now also works for `const` values.\n [#260](https://github.com/pybind/pybind11/pull/260).\n\n- `make_iterator()` improvements for better compatibility with various\n types (now uses prefix increment operator); it now also accepts\n iterators with different begin/end types as long as they are equality\n comparable. [#247](https://github.com/pybind/pybind11/pull/247).\n\n- `arg()` now accepts a wider range of argument types for default\n values. [#244](https://github.com/pybind/pybind11/pull/244).\n\n- Support `keep_alive` where the nurse object may be `None`.\n [#341](https://github.com/pybind/pybind11/pull/341).\n\n- Added constructors for `str` and `bytes` from zero-terminated char\n pointers, and from char pointers and length. Added constructors for\n `str` from `bytes` and for `bytes` from `str`, which will perform\n UTF-8 decoding/encoding as required.\n\n- Many other improvements of library internals without user-visible\n changes\n\n## 1.8.1 (July 12, 2016)\n\n- Fixed a rare but potentially very severe issue when the garbage\n collector ran during pybind11 type creation.\n\n## 1.8.0 (June 14, 2016)\n\n- Redesigned CMake build system which exports a convenient\n `pybind11_add_module` function to parent projects.\n- `std::vector<>` type bindings analogous to Boost.Python's\n `indexing_suite`\n- Transparent conversion of sparse and dense Eigen matrices and vectors\n (`eigen.h`)\n- Added an `ExtraFlags` template argument to the NumPy `array_t<>`\n wrapper to disable an enforced cast that may lose precision, e.g. to\n create overloads for different precisions and complex vs real-valued\n matrices.\n- Prevent implicit conversion of floating point values to integral types\n in function arguments\n- Fixed incorrect default return value policy for functions returning a\n shared pointer\n- Don't allow registering a type via `class_` twice\n- Don't allow casting a `None` value into a C++ lvalue reference\n- Fixed a crash in `enum_::operator==` that was triggered by the\n `help()` command\n- Improved detection of whether or not custom C++ types can be\n copy/move-constructed\n- Extended `str` type to also work with `bytes` instances\n- Added a `\"name\"_a` user defined string literal that is equivalent to\n `py::arg(\"name\")`.\n- When specifying function arguments via `py::arg`, the test that\n verifies the number of arguments now runs at compile time.\n- Added `[[noreturn]]` attribute to `pybind11_fail()` to quench some\n compiler warnings\n- List function arguments in exception text when the dispatch code\n cannot find a matching overload\n- Added `PYBIND11_OVERLOAD_NAME` and `PYBIND11_OVERLOAD_PURE_NAME`\n macros which can be used to override virtual methods whose name\n differs in C++ and Python (e.g. `__call__` and `operator()`)\n- Various minor `iterator` and `make_iterator()` improvements\n- Transparently support `__bool__` on Python 2.x and Python 3.x\n- Fixed issue with destructor of unpickled object not being called\n- Minor CMake build system improvements on Windows\n- New `pybind11::args` and `pybind11::kwargs` types to create functions\n which take an arbitrary number of arguments and keyword arguments\n- New syntax to call a Python function from C++ using `*args` and\n `*kwargs`\n- The functions `def_property_*` now correctly process docstring\n arguments (these formerly caused a segmentation fault)\n- Many `mkdoc.py` improvements (enumerations, template arguments,\n `DOC()` macro accepts more arguments)\n- Cygwin support\n- Documentation improvements (pickling support, `keep_alive`, macro\n usage)\n\n## 1.7 (April 30, 2016)\n\n- Added a new `move` return value policy that triggers C++11 move\n semantics. The automatic return value policy falls back to this case\n whenever a rvalue reference is encountered\n- Significantly more general GIL state routines that are used instead of\n Python's troublesome `PyGILState_Ensure` and `PyGILState_Release` API\n- Redesign of opaque types that drastically simplifies their usage\n- Extended ability to pass values of type `[const] void *`\n- `keep_alive` fix: don't fail when there is no patient\n- `functional.h`: acquire the GIL before calling a Python function\n- Added Python RAII type wrappers `none` and `iterable`\n- Added `*args` and `*kwargs` pass-through parameters to\n `pybind11.get_include()` function\n- Iterator improvements and fixes\n- Documentation on return value policies and opaque types improved\n\n## 1.6 (April 30, 2016)\n\n- Skipped due to upload to PyPI gone wrong and inability to recover\n ()\n\n## 1.5 (April 21, 2016)\n\n- For polymorphic types, use RTTI to try to return the closest type\n registered with pybind11\n- Pickling support for serializing and unserializing C++ instances to a\n byte stream in Python\n- Added a convenience routine `make_iterator()` which turns a range\n indicated by a pair of C++ iterators into a iterable Python object\n- Added `len()` and a variadic `make_tuple()` function\n- Addressed a rare issue that could confuse the current virtual function\n dispatcher and another that could lead to crashes in multi-threaded\n applications\n- Added a `get_include()` function to the Python module that returns the\n path of the directory containing the installed pybind11 header files\n- Documentation improvements: import issues, symbol visibility,\n pickling, limitations\n- Added casting support for `std::reference_wrapper<>`\n\n## 1.4 (April 7, 2016)\n\n- Transparent type conversion for `std::wstring` and `wchar_t`\n- Allow passing `nullptr`-valued strings\n- Transparent passing of `void *` pointers using capsules\n- Transparent support for returning values wrapped in\n `std::unique_ptr<>`\n- Improved docstring generation for compatibility with Sphinx\n- Nicer debug error message when default parameter construction fails\n- Support for \"opaque\" types that bypass the transparent conversion\n layer for STL containers\n- Redesigned type casting interface to avoid ambiguities that could\n occasionally cause compiler errors\n- Redesigned property implementation; fixes crashes due to an\n unfortunate default return value policy\n- Anaconda package generation support\n\n## 1.3 (March 8, 2016)\n\n- Added support for the Intel C++ compiler (v15+)\n- Added support for the STL unordered set/map data structures\n- Added support for the STL linked list data structure\n- NumPy-style broadcasting support in `pybind11::vectorize`\n- pybind11 now displays more verbose error messages when\n `arg::operator=()` fails\n- pybind11 internal data structures now live in a version-dependent\n namespace to avoid ABI issues\n- Many, many bugfixes involving corner cases and advanced usage\n\n## 1.2 (February 7, 2016)\n\n- Optional: efficient generation of function signatures at compile time\n using C++14\n- Switched to a simpler and more general way of dealing with function\n default arguments. Unused keyword arguments in function calls are now\n detected and cause errors as expected\n- New `keep_alive` call policy analogous to Boost.Python's\n `with_custodian_and_ward`\n- New `pybind11::base<>` attribute to indicate a subclass relationship\n- Improved interface for RAII type wrappers in `pytypes.h`\n- Use RAII type wrappers consistently within pybind11 itself. This fixes\n various potential refcount leaks when exceptions occur\n- Added new `bytes` RAII type wrapper (maps to `string` in Python 2.7)\n- Made handle and related RAII classes const correct, using them more\n consistently everywhere now\n- Got rid of the ugly `__pybind11__` attributes on the Python\n side---they are now stored in a C++ hash table that is not visible in\n Python\n- Fixed refcount leaks involving NumPy arrays and bound functions\n- Vastly improved handling of shared/smart pointers\n- Removed an unnecessary copy operation in `pybind11::vectorize`\n- Fixed naming clashes when both pybind11 and NumPy headers are included\n- Added conversions for additional exception types\n- Documentation improvements (using multiple extension modules, smart\n pointers, other minor clarifications)\n- unified infrastructure for parsing variadic arguments in `class_` and\n cpp_function\n- Fixed license text (was: ZLIB, should have been: 3-clause BSD)\n- Python 3.2 compatibility\n- Fixed remaining issues when accessing types in another plugin module\n- Added enum comparison and casting methods\n- Improved SFINAE-based detection of whether types are\n copy-constructible\n- Eliminated many warnings about unused variables and the use of\n `offsetof()`\n- Support for `std::array<>` conversions\n\n## 1.1 (December 7, 2015)\n\n- Documentation improvements (GIL, wrapping functions, casting, fixed\n many typos)\n- Generalized conversion of integer types\n- Improved support for casting function objects\n- Improved support for `std::shared_ptr<>` conversions\n- Initial support for `std::set<>` conversions\n- Fixed type resolution issue for types defined in a separate plugin\n module\n- CMake build system improvements\n- Factored out generic functionality to non-templated code (smaller code\n size)\n- Added a code size / compile time benchmark vs Boost.Python\n- Added an appveyor CI script\n\n## 1.0 (October 15, 2015)\n\n- Initial release\n" }, { "path": "docs/classes.rst", "content": ".. _classes:\n\nObject-oriented code\n####################\n\nCreating bindings for a custom type\n===================================\n\nLet's now look at a more complex example where we'll create bindings for a\ncustom C++ data structure named ``Pet``. Its definition is given below:\n\n.. code-block:: cpp\n\n struct Pet {\n Pet(const std::string &name) : name(name) { }\n void setName(const std::string &name_) { name = name_; }\n const std::string &getName() const { return name; }\n\n std::string name;\n };\n\nThe binding code for ``Pet`` looks as follows:\n\n.. code-block:: cpp\n\n #include \n\n namespace py = pybind11;\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n py::class_(m, \"Pet\")\n .def(py::init())\n .def(\"setName\", &Pet::setName)\n .def(\"getName\", &Pet::getName);\n }\n\n``py::class_`` creates bindings for a C++ *class* or *struct*-style data\nstructure. :func:`init` is a convenience function that takes the types of a\nconstructor's parameters as template arguments and wraps the corresponding\nconstructor (see the :ref:`custom_constructors` section for details).\n\n.. note::\n\n Starting with pybind11v3, it is recommended to include `py::smart_holder`\n in most situations for safety, especially if you plan to support conversions\n to C++ smart pointers. See :ref:`smart_holder` for more information.\n\nAn interactive Python session demonstrating this example is shown below:\n\n.. code-block:: pycon\n\n % python\n >>> import example\n >>> p = example.Pet(\"Molly\")\n >>> print(p)\n \n >>> p.getName()\n 'Molly'\n >>> p.setName(\"Charly\")\n >>> p.getName()\n 'Charly'\n\n.. seealso::\n\n Static member functions can be bound in the same way using\n :func:`class_::def_static`.\n\n.. note::\n\n Binding C++ types in unnamed namespaces (also known as anonymous namespaces)\n works reliably on many platforms, but not all. The `XFAIL_CONDITION` in\n tests/test_unnamed_namespace_a.py encodes the currently known conditions.\n For background see `#4319 `_.\n If portability is a concern, it is therefore not recommended to bind C++\n types in unnamed namespaces. It will be safest to manually pick unique\n namespace names.\n\nKeyword and default arguments\n=============================\nIt is possible to specify keyword and default arguments using the syntax\ndiscussed in the previous chapter. Refer to the sections :ref:`keyword_args`\nand :ref:`default_args` for details.\n\nBinding lambda functions\n========================\n\nNote how ``print(p)`` produced a rather useless summary of our data structure in the example above:\n\n.. code-block:: pycon\n\n >>> print(p)\n \n\nTo address this, we could bind a utility function that returns a human-readable\nsummary to the special method slot named ``__repr__``. Unfortunately, there is no\nsuitable functionality in the ``Pet`` data structure, and it would be nice if\nwe did not have to change it. This can easily be accomplished by binding a\nLambda function instead:\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(py::init())\n .def(\"setName\", &Pet::setName)\n .def(\"getName\", &Pet::getName)\n .def(\"__repr__\",\n [](const Pet &a) {\n return \"\";\n }\n );\n\nBoth stateless [#f1]_ and stateful lambda closures are supported by pybind11.\nWith the above change, the same Python code now produces the following output:\n\n.. code-block:: pycon\n\n >>> print(p)\n \n\n.. [#f1] Stateless closures are those with an empty pair of brackets ``[]`` as the capture object.\n\n.. _properties:\n\nInstance and static fields\n==========================\n\nWe can also directly expose the ``name`` field using the\n:func:`class_::def_readwrite` method. A similar :func:`class_::def_readonly`\nmethod also exists for ``const`` fields.\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(py::init())\n .def_readwrite(\"name\", &Pet::name)\n // ... remainder ...\n\nThis makes it possible to write\n\n.. code-block:: pycon\n\n >>> p = example.Pet(\"Molly\")\n >>> p.name\n 'Molly'\n >>> p.name = \"Charly\"\n >>> p.name\n 'Charly'\n\nNow suppose that ``Pet::name`` was a private internal variable\nthat can only be accessed via setters and getters.\n\n.. code-block:: cpp\n\n class Pet {\n public:\n Pet(const std::string &name) : name(name) { }\n void setName(const std::string &name_) { name = name_; }\n const std::string &getName() const { return name; }\n private:\n std::string name;\n };\n\nIn this case, the method :func:`class_::def_property`\n(:func:`class_::def_property_readonly` for read-only data) can be used to\nprovide a field-like interface within Python that will transparently call\nthe setter and getter functions:\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(py::init())\n .def_property(\"name\", &Pet::getName, &Pet::setName)\n // ... remainder ...\n\nWrite only properties can be defined by passing ``nullptr`` as the\ninput for the read function.\n\n.. seealso::\n\n Similar functions :func:`class_::def_readwrite_static`,\n :func:`class_::def_readonly_static` :func:`class_::def_property_static`,\n and :func:`class_::def_property_readonly_static` are provided for binding\n static variables and properties. Please also see the section on\n :ref:`static_properties` in the advanced part of the documentation.\n\nDynamic attributes\n==================\n\nNative Python classes can pick up new attributes dynamically:\n\n.. code-block:: pycon\n\n >>> class Pet:\n ... name = \"Molly\"\n ...\n >>> p = Pet()\n >>> p.name = \"Charly\" # overwrite existing\n >>> p.age = 2 # dynamically add a new attribute\n\nBy default, classes exported from C++ do not support this and the only writable\nattributes are the ones explicitly defined using :func:`class_::def_readwrite`\nor :func:`class_::def_property`.\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(py::init<>())\n .def_readwrite(\"name\", &Pet::name);\n\nTrying to set any other attribute results in an error:\n\n.. code-block:: pycon\n\n >>> p = example.Pet()\n >>> p.name = \"Charly\" # OK, attribute defined in C++\n >>> p.age = 2 # fail\n AttributeError: 'Pet' object has no attribute 'age'\n\nTo enable dynamic attributes for C++ classes, the :class:`py::dynamic_attr` tag\nmust be added to the :class:`py::class_` constructor:\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\", py::dynamic_attr())\n .def(py::init<>())\n .def_readwrite(\"name\", &Pet::name);\n\nNow everything works as expected:\n\n.. code-block:: pycon\n\n >>> p = example.Pet()\n >>> p.name = \"Charly\" # OK, overwrite value in C++\n >>> p.age = 2 # OK, dynamically add a new attribute\n >>> p.__dict__ # just like a native Python class\n {'age': 2}\n\nNote that there is a small runtime cost for a class with dynamic attributes.\nNot only because of the addition of a ``__dict__``, but also because of more\nexpensive garbage collection tracking which must be activated to resolve\npossible circular references. Native Python classes incur this same cost by\ndefault, so this is not anything to worry about. By default, pybind11 classes\nare more efficient than native Python classes. Enabling dynamic attributes\njust brings them on par.\n\n.. _inheritance:\n\nInheritance and automatic downcasting\n=====================================\n\nSuppose now that the example consists of two data structures with an\ninheritance relationship:\n\n.. code-block:: cpp\n\n struct Pet {\n Pet(const std::string &name) : name(name) { }\n std::string name;\n };\n\n struct Dog : Pet {\n Dog(const std::string &name) : Pet(name) { }\n std::string bark() const { return \"woof!\"; }\n };\n\nThere are two different ways of indicating a hierarchical relationship to\npybind11: the first specifies the C++ base class as an extra template\nparameter of the ``py::class_``:\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(py::init())\n .def_readwrite(\"name\", &Pet::name);\n\n // Method 1: template parameter:\n py::class_(m, \"Dog\")\n .def(py::init())\n .def(\"bark\", &Dog::bark);\n\nAlternatively, we can also assign a name to the previously bound ``Pet``\n``py::class_`` object and reference it when binding the ``Dog`` class:\n\n.. code-block:: cpp\n\n py::class_ pet(m, \"Pet\");\n pet.def(py::init())\n .def_readwrite(\"name\", &Pet::name);\n\n // Method 2: pass parent class_ object:\n py::class_(m, \"Dog\", pet /* <- specify Python parent type */)\n .def(py::init())\n .def(\"bark\", &Dog::bark);\n\nFunctionality-wise, both approaches are equivalent. Afterwards, instances will\nexpose fields and methods of both types:\n\n.. code-block:: pycon\n\n >>> p = example.Dog(\"Molly\")\n >>> p.name\n 'Molly'\n >>> p.bark()\n 'woof!'\n\nThe C++ classes defined above are regular non-polymorphic types with an\ninheritance relationship. This is reflected in Python:\n\n.. code-block:: cpp\n\n // Return a base pointer to a derived instance\n m.def(\"pet_store\", []() { return std::unique_ptr(new Dog(\"Molly\")); });\n\n.. code-block:: pycon\n\n >>> p = example.pet_store()\n >>> type(p) # `Dog` instance behind `Pet` pointer\n Pet # no pointer downcasting for regular non-polymorphic types\n >>> p.bark()\n AttributeError: 'Pet' object has no attribute 'bark'\n\nThe function returned a ``Dog`` instance, but because it's a non-polymorphic\ntype behind a base pointer, Python only sees a ``Pet``. In C++, a type is only\nconsidered polymorphic if it has at least one virtual function and pybind11\nwill automatically recognize this:\n\n.. code-block:: cpp\n\n struct PolymorphicPet {\n virtual ~PolymorphicPet() = default;\n };\n\n struct PolymorphicDog : PolymorphicPet {\n std::string bark() const { return \"woof!\"; }\n };\n\n // Same binding code\n py::class_(m, \"PolymorphicPet\");\n py::class_(m, \"PolymorphicDog\")\n .def(py::init<>())\n .def(\"bark\", &PolymorphicDog::bark);\n\n // Again, return a base pointer to a derived instance\n m.def(\"pet_store2\", []() { return std::unique_ptr(new PolymorphicDog); });\n\n.. code-block:: pycon\n\n >>> p = example.pet_store2()\n >>> type(p)\n PolymorphicDog # automatically downcast\n >>> p.bark()\n 'woof!'\n\nGiven a pointer to a polymorphic base, pybind11 performs automatic downcasting\nto the actual derived type. Note that this goes beyond the usual situation in\nC++: we don't just get access to the virtual functions of the base, we get the\nconcrete derived type including functions and attributes that the base type may\nnot even be aware of.\n\n.. seealso::\n\n For more information about polymorphic behavior see :ref:`overriding_virtuals`.\n\n\nOverloaded methods\n==================\n\nSometimes there are several overloaded C++ methods with the same name taking\ndifferent kinds of input arguments:\n\n.. code-block:: cpp\n\n struct Pet {\n Pet(const std::string &name, int age) : name(name), age(age) { }\n\n void set(int age_) { age = age_; }\n void set(const std::string &name_) { name = name_; }\n\n std::string name;\n int age;\n };\n\nAttempting to bind ``Pet::set`` will cause an error since the compiler does not\nknow which method the user intended to select. We can disambiguate by casting\nthem to function pointers. Binding multiple functions to the same Python name\nautomatically creates a chain of function overloads that will be tried in\nsequence.\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(py::init())\n .def(\"set\", static_cast(&Pet::set), \"Set the pet's age\")\n .def(\"set\", static_cast(&Pet::set), \"Set the pet's name\");\n\nThe overload signatures are also visible in the method's docstring:\n\n.. code-block:: pycon\n\n >>> help(example.Pet)\n\n class Pet(__builtin__.object)\n | Methods defined here:\n |\n | __init__(...)\n | Signature : (Pet, str, int) -> NoneType\n |\n | set(...)\n | 1. Signature : (Pet, int) -> NoneType\n |\n | Set the pet's age\n |\n | 2. Signature : (Pet, str) -> NoneType\n |\n | Set the pet's name\n\nIf you have a C++14 compatible compiler [#cpp14]_, you can use an alternative\nsyntax to cast the overloaded function:\n\n.. code-block:: cpp\n\n py::class_(m, \"Pet\")\n .def(\"set\", py::overload_cast(&Pet::set), \"Set the pet's age\")\n .def(\"set\", py::overload_cast(&Pet::set), \"Set the pet's name\");\n\nHere, ``py::overload_cast`` only requires the parameter types to be specified.\nThe return type and class are deduced. This avoids the additional noise of\n``void (Pet::*)()`` as seen in the raw cast. If a function is overloaded based\non constness, the ``py::const_`` tag should be used:\n\n.. code-block:: cpp\n\n struct Widget {\n int foo(int x, float y);\n int foo(int x, float y) const;\n };\n\n py::class_(m, \"Widget\")\n .def(\"foo_mutable\", py::overload_cast(&Widget::foo))\n .def(\"foo_const\", py::overload_cast(&Widget::foo, py::const_));\n\nIf you prefer the ``py::overload_cast`` syntax but have a C++11 compatible compiler only,\nyou can use ``py::detail::overload_cast_impl`` with an additional set of parentheses:\n\n.. code-block:: cpp\n\n template \n using overload_cast_ = pybind11::detail::overload_cast_impl;\n\n py::class_(m, \"Pet\")\n .def(\"set\", overload_cast_()(&Pet::set), \"Set the pet's age\")\n .def(\"set\", overload_cast_()(&Pet::set), \"Set the pet's name\");\n\n.. [#cpp14] A compiler which supports the ``-std=c++14`` flag.\n\n.. note::\n\n To define multiple overloaded constructors, simply declare one after the\n other using the ``.def(py::init<...>())`` syntax. The existing machinery\n for specifying keyword and default arguments also works.\n\n☝️ Pitfalls with raw pointers and shared ownership\n==================================================\n\n``py::class_``-wrapped objects automatically manage the lifetime of the\nwrapped C++ object, in collaboration with the chosen holder type (see\n:ref:`py_class_holder`). When wrapping C++ functions involving raw pointers,\ncare needs to be taken to not accidentally undermine automatic lifetime\nmanagement. For example, ownership is inadvertently transferred here:\n\n.. code-block:: cpp\n\n class Child { };\n\n class Parent {\n public:\n Parent() : child(std::make_shared()) { }\n Child *get_child() { return child.get(); } /* DANGER */\n private:\n std::shared_ptr child;\n };\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n py::class_>(m, \"Child\");\n\n py::class_>(m, \"Parent\")\n .def(py::init<>())\n .def(\"get_child\", &Parent::get_child); /* PROBLEM */\n }\n\nThe following Python code leads to undefined behavior, likely resulting in\na segmentation fault.\n\n.. code-block:: python\n\n from example import Parent\n\n print(Parent().get_child())\n\nPart of the ``/* PROBLEM */`` here is that pybind11 falls back to using\n``return_value_policy::take_ownership`` as the default (see\n:ref:`return_value_policies`). The fact that the ``Child`` instance is\nalready managed by ``std::shared_ptr`` is lost. Therefore pybind11\nwill create a second independent ``std::shared_ptr`` that also\nclaims ownership of the pointer, eventually leading to heap-use-after-free\nor double-free errors.\n\nThere are various ways to resolve this issue, either by changing\nthe ``Child`` or ``Parent`` C++ implementations (e.g. using\n``std::enable_shared_from_this`` as a base class for\n``Child``, or adding a member function to ``Parent`` that returns\n``std::shared_ptr``), or if that is not feasible, by using\n``return_value_policy::reference_internal``. What is the best approach\ndepends on the exact situation.\n\nA highly effective way to stay in the clear — even in pure C++, but\nespecially when binding C++ code to Python — is to consistently prefer\n``std::shared_ptr`` or ``std::unique_ptr`` over passing raw pointers.\n\n.. _native_enum:\n\nEnumerations and internal types\n===============================\n\nLet's now suppose that the example class contains internal types like enumerations, e.g.:\n\n.. code-block:: cpp\n\n struct Pet {\n enum Kind {\n Dog = 0,\n Cat\n };\n\n struct Attributes {\n float age = 0;\n };\n\n Pet(const std::string &name, Kind type) : name(name), type(type) { }\n\n std::string name;\n Kind type;\n Attributes attr;\n };\n\nThe binding code for this example looks as follows:\n\n.. code-block:: cpp\n\n #include // Not already included with pybind11.h\n\n py::class_ pet(m, \"Pet\");\n\n pet.def(py::init())\n .def_readwrite(\"name\", &Pet::name)\n .def_readwrite(\"type\", &Pet::type)\n .def_readwrite(\"attr\", &Pet::attr);\n\n py::native_enum(pet, \"Kind\", \"enum.Enum\")\n .value(\"Dog\", Pet::Kind::Dog)\n .value(\"Cat\", Pet::Kind::Cat)\n .export_values()\n .finalize();\n\n py::class_(pet, \"Attributes\")\n .def(py::init<>())\n .def_readwrite(\"age\", &Pet::Attributes::age);\n\n\nTo ensure that the nested types ``Kind`` and ``Attributes`` are created\nwithin the scope of ``Pet``, the ``pet`` ``py::class_`` instance must be\nsupplied to the ``py::native_enum`` and ``py::class_`` constructors. The\n``.export_values()`` function is available for exporting the enum entries\ninto the parent scope, if desired.\n\n``py::native_enum`` was introduced with pybind11v3. It binds C++ enum types\nto native Python enum types, typically types in Python's\n`stdlib enum `_ module,\nwhich are `PEP 435 compatible `_.\nThis is the recommended way to bind C++ enums.\nThe older ``py::enum_`` is not PEP 435 compatible\n(see `issue #2332 `_)\nbut remains supported indefinitely for backward compatibility.\nNew bindings should prefer ``py::native_enum``.\n\n.. note::\n\n The deprecated ``py::enum_`` is :ref:`documented here `.\n\nThe ``.finalize()`` call above is needed because Python's native enums\ncannot be built incrementally — all name/value pairs need to be passed at\nonce. To achieve this, ``py::native_enum`` acts as a buffer to collect the\nname/value pairs. The ``.finalize()`` call uses the accumulated name/value\npairs to build the arguments for constructing a native Python enum type.\n\nThe ``py::native_enum`` constructor takes a third argument,\n``native_type_name``, which specifies the fully qualified name of the Python\nbase class to use — e.g., ``\"enum.Enum\"`` or ``\"enum.IntEnum\"``. A fourth\noptional argument, ``class_doc``, provides the docstring for the generated\nclass.\n\nFor example:\n\n.. code-block:: cpp\n\n py::native_enum(pet, \"Kind\", \"enum.IntEnum\", \"Constant specifying the kind of pet\")\n\nYou may use any fully qualified Python name for ``native_type_name``.\nThe only requirement is that the named type is similar to\n`enum.Enum `_\nin these ways:\n\n* Has a `constructor similar to that of enum.Enum\n `_::\n\n Colors = enum.Enum(\"Colors\", ((\"Red\", 0), (\"Green\", 1)))\n\n* A `C++ underlying `_\n enum value can be passed to the constructor for the Python enum value::\n\n red = Colors(0)\n\n* The enum values have a ``.value`` property yielding a value that\n can be cast to the C++ underlying type::\n\n underlying = red.value\n\nAs of Python 3.13, the compatible `types in the stdlib enum module\n`_ are:\n``Enum``, ``IntEnum``, ``Flag``, ``IntFlag``.\n\n.. note::\n\n In rare cases, a C++ enum may be bound to Python via a\n :ref:`custom type caster `. In such cases, a\n template specialization like this may be required:\n\n .. code-block:: cpp\n\n #if defined(PYBIND11_HAS_NATIVE_ENUM)\n namespace pybind11::detail {\n template \n struct type_caster_enum_type_enabled<\n FancyEnum,\n enable_if_t::value>> : std::false_type {};\n }\n #endif\n\n This specialization is needed only if the custom type caster is templated.\n\n The ``PYBIND11_HAS_NATIVE_ENUM`` guard is needed only if backward\n compatibility with pybind11v2 is required.\n" }, { "path": "docs/cmake/index.rst", "content": "CMake helpers\n-------------\n\nPybind11 can be used with ``add_subdirectory(extern/pybind11)``, or from an\ninstall with ``find_package(pybind11 CONFIG)``. The interface provided in\neither case is functionally identical.\n\n.. cmake-module:: ../../tools/pybind11Config.cmake.in\n" }, { "path": "docs/compiling.rst", "content": ".. _compiling:\n\nBuild systems\n#############\n\nFor an overview of Python packaging including compiled packaging with a pybind11\nexample, along with a cookiecutter that includes several pybind11 options, see\nthe `Scientific Python Development Guide`_.\n\n.. _Scientific Python Development Guide: https://learn.scientific-python.org/development/guides/packaging-compiled/\n\n.. scikit-build-core:\n\nModules with CMake\n==================\n\nA Python extension module can be created with just a few lines of code:\n\n.. code-block:: cmake\n\n cmake_minimum_required(VERSION 3.15...4.2)\n project(example LANGUAGES CXX)\n\n set(PYBIND11_FINDPYTHON ON)\n find_package(pybind11 CONFIG REQUIRED)\n\n pybind11_add_module(example example.cpp)\n install(TARGETS example DESTINATION .)\n\n(You use the ``add_subdirectory`` instead, see the example in :ref:`cmake`.) In\nthis example, the code is located in a file named :file:`example.cpp`. Either\nmethod will import the pybind11 project which provides the\n``pybind11_add_module`` function. It will take care of all the details needed\nto build a Python extension module on any platform.\n\nTo build with pip, build, cibuildwheel, uv, or other Python tools, you can\nadd a ``pyproject.toml`` file like this:\n\n.. code-block:: toml\n\n [build-system]\n requires = [\"scikit-build-core\", \"pybind11\"]\n build-backend = \"scikit_build_core.build\"\n\n [project]\n name = \"example\"\n version = \"0.1.0\"\n\nYou don't need setuptools files like ``MANIFEST.in``, ``setup.py``, or\n``setup.cfg``, as this is not setuptools. See `scikit-build-core`_ for details.\nFor projects you plan to upload to PyPI, be sure to fill out the ``[project]``\ntable with other important metadata as well (see `Writing pyproject.toml`_).\n\nA working sample project can be found in the [scikit_build_example]_\nrepository. An older and harder-to-maintain method is in [cmake_example]_. More\ndetails about our cmake support can be found below in :ref:`cmake`.\n\n.. _scikit-build-core: https://scikit-build-core.readthedocs.io\n\n.. [scikit_build_example] https://github.com/pybind/scikit_build_example\n\n.. [cmake_example] https://github.com/pybind/cmake_example\n\n.. _modules-meson-python:\n\nModules with meson-python\n=========================\n\nYou can also build a package with `Meson`_ using `meson-python`_, if you prefer\nthat. Your ``meson.build`` file would look something like this:\n\n.. _meson-example:\n\n.. code-block:: meson\n\n project(\n 'example',\n 'cpp',\n version: '0.1.0',\n default_options: [\n 'cpp_std=c++11',\n ],\n )\n\n py = import('python').find_installation(pure: false)\n pybind11_dep = dependency('pybind11')\n\n py.extension_module('example',\n 'example.cpp',\n install: true,\n dependencies : [pybind11_dep],\n )\n\n\nAnd you would need a ``pyproject.toml`` file like this:\n\n.. code-block:: toml\n\n [build-system]\n requires = [\"meson-python\", \"pybind11\"]\n build-backend = \"mesonpy\"\n\nMeson-python *requires* your project to be in git (or mercurial) as it uses it\nfor the SDist creation. For projects you plan to upload to PyPI, be sure to fill out the\n``[project]`` table as well (see `Writing pyproject.toml`_).\n\n\n.. _Writing pyproject.toml: https://packaging.python.org/en/latest/guides/writing-pyproject-toml\n\n.. _meson: https://mesonbuild.com\n\n.. _meson-python: https://meson-python.readthedocs.io/en/latest\n\n.. _build-setuptools:\n\nModules with setuptools\n=======================\n\nFor projects on PyPI, a historically popular option is setuptools. Sylvain\nCorlay has kindly provided an example project which shows how to set up\neverything, including automatic generation of documentation using Sphinx.\nPlease refer to the [python_example]_ repository.\n\n.. [python_example] https://github.com/pybind/python_example\n\nA helper file is provided with pybind11 that can simplify usage with setuptools.\n\nTo use pybind11 inside your ``setup.py``, you have to have some system to\nensure that ``pybind11`` is installed when you build your package. There are\nfour possible ways to do this, and pybind11 supports all four: You can ask all\nusers to install pybind11 beforehand (bad), you can use\n:ref:`setup_helpers-pep518` (good), ``setup_requires=`` (discouraged), or you\ncan :ref:`setup_helpers-copy-manually` (works but you have to manually sync\nyour copy to get updates). Third party packagers like conda-forge generally\nstrongly prefer the ``pyproject.toml`` method, as it gives them control over\nthe ``pybind11`` version, and they may apply patches, etc.\n\nAn example of a ``setup.py`` using pybind11's helpers:\n\n.. code-block:: python\n\n from glob import glob\n from setuptools import setup\n from pybind11.setup_helpers import Pybind11Extension\n\n ext_modules = [\n Pybind11Extension(\n \"python_example\",\n sorted(glob(\"src/*.cpp\")), # Sort source files for reproducibility\n ),\n ]\n\n setup(..., ext_modules=ext_modules)\n\nIf you want to do an automatic search for the highest supported C++ standard,\nthat is supported via a ``build_ext`` command override; it will only affect\n``Pybind11Extensions``:\n\n.. code-block:: python\n\n from glob import glob\n from setuptools import setup\n from pybind11.setup_helpers import Pybind11Extension, build_ext\n\n ext_modules = [\n Pybind11Extension(\n \"python_example\",\n sorted(glob(\"src/*.cpp\")),\n ),\n ]\n\n setup(..., cmdclass={\"build_ext\": build_ext}, ext_modules=ext_modules)\n\nIf you have single-file extension modules that are directly stored in the\nPython source tree (``foo.cpp`` in the same directory as where a ``foo.py``\nwould be located), you can also generate ``Pybind11Extensions`` using\n``setup_helpers.intree_extensions``: ``intree_extensions([\"path/to/foo.cpp\",\n...])`` returns a list of ``Pybind11Extensions`` which can be passed to\n``ext_modules``, possibly after further customizing their attributes\n(``libraries``, ``include_dirs``, etc.). By doing so, a ``foo.*.so`` extension\nmodule will be generated and made available upon installation.\n\n``intree_extension`` will automatically detect if you are using a ``src``-style\nlayout (as long as no namespace packages are involved), but you can also\nexplicitly pass ``package_dir`` to it (as in ``setuptools.setup``).\n\nSince pybind11 does not require NumPy when building, a light-weight replacement\nfor NumPy's parallel compilation distutils tool is included. Use it like this:\n\n.. code-block:: python\n\n from pybind11.setup_helpers import ParallelCompile\n\n # Optional multithreaded build\n ParallelCompile(\"NPY_NUM_BUILD_JOBS\").install()\n\n setup(...)\n\nThe argument is the name of an environment variable to control the number of\nthreads, such as ``NPY_NUM_BUILD_JOBS`` (as used by NumPy), though you can set\nsomething different if you want; ``CMAKE_BUILD_PARALLEL_LEVEL`` is another choice\na user might expect. You can also pass ``default=N`` to set the default number\nof threads (0 will take the number of threads available) and ``max=N``, the\nmaximum number of threads; if you have a large extension you may want set this\nto a memory dependent number.\n\nIf you are developing rapidly and have a lot of C++ files, you may want to\navoid rebuilding files that have not changed. For simple cases were you are\nusing ``pip install -e .`` and do not have local headers, you can skip the\nrebuild if an object file is newer than its source (headers are not checked!)\nwith the following:\n\n.. code-block:: python\n\n from pybind11.setup_helpers import ParallelCompile, naive_recompile\n\n ParallelCompile(\"NPY_NUM_BUILD_JOBS\", needs_recompile=naive_recompile).install()\n\n\nIf you have a more complex build, you can implement a smarter function and pass\nit to ``needs_recompile``, or you can use [Ccache]_ instead. ``CXX=\"cache g++\"\npip install -e .`` would be the way to use it with GCC, for example. Unlike the\nsimple solution, this even works even when not compiling in editable mode, but\nit does require Ccache to be installed.\n\nKeep in mind that Pip will not even attempt to rebuild if it thinks it has\nalready built a copy of your code, which it deduces from the version number.\nOne way to avoid this is to use [setuptools_scm]_, which will generate a\nversion number that includes the number of commits since your last tag and a\nhash for a dirty directory. Another way to force a rebuild is purge your cache\nor use Pip's ``--no-cache-dir`` option.\n\nYou also need a ``MANIFEST.in`` file to include all relevant files so that you\ncan make an SDist. If you use `pypa-build`_, that will build an SDist then a\nwheel from that SDist by default, so you can look inside those files (wheels\nare just zip files with a ``.whl`` extension) to make sure you aren't missing\nfiles. `check-manifest`_ (setuptools specific) or `check-sdist`_ (general) are\nCLI tools that can compare the SDist contents with your source control.\n\n.. [Ccache] https://ccache.dev\n\n.. [setuptools_scm] https://github.com/pypa/setuptools_scm\n\n.. _setup_helpers-pep518:\n\nBuild requirements\n------------------\n\nWith a ``pyproject.toml`` file, you can ensure that ``pybind11`` is available\nduring the compilation of your project. When this file exists, Pip will make a\nnew virtual environment, download just the packages listed here in\n``requires=``, and build a wheel (binary Python package). It will then throw\naway the environment, and install your wheel.\n\nYour ``pyproject.toml`` file will likely look something like this:\n\n.. code-block:: toml\n\n [build-system]\n requires = [\"setuptools\", \"pybind11\"]\n build-backend = \"setuptools.build_meta\"\n\n.. _PEP 517: https://www.python.org/dev/peps/pep-0517/\n.. _cibuildwheel: https://cibuildwheel.pypa.io\n.. _pypa-build: https://build.pypa.io/en/latest/\n.. _check-manifest: https://pypi.io/project/check-manifest\n.. _check-sdist: https://pypi.io/project/check-sdist\n\n.. _setup_helpers-copy-manually:\n\nCopy manually\n-------------\n\nYou can also copy ``setup_helpers.py`` directly to your project; it was\ndesigned to be usable standalone, like the old example ``setup.py``. You can\nset ``include_pybind11=False`` to skip including the pybind11 package headers,\nso you can use it with git submodules and a specific git version. If you use\nthis, you will need to import from a local file in ``setup.py`` and ensure the\nhelper file is part of your MANIFEST.\n\n\nClosely related, if you include pybind11 as a subproject, you can run the\n``setup_helpers.py`` inplace. If loaded correctly, this should even pick up\nthe correct include for pybind11, though you can turn it off as shown above if\nyou want to input it manually.\n\nSuggested usage if you have pybind11 as a submodule in ``extern/pybind11``:\n\n.. code-block:: python\n\n DIR = os.path.abspath(os.path.dirname(__file__))\n\n sys.path.append(os.path.join(DIR, \"extern\", \"pybind11\"))\n from pybind11.setup_helpers import Pybind11Extension # noqa: E402\n\n del sys.path[-1]\n\n\n.. versionchanged:: 2.6\n\n Added ``setup_helpers`` file.\n\nBuilding with cppimport\n========================\n\n[cppimport]_ is a small Python import hook that determines whether there is a C++\nsource file whose name matches the requested module. If there is, the file is\ncompiled as a Python extension using pybind11 and placed in the same folder as\nthe C++ source file. Python is then able to find the module and load it.\n\n.. [cppimport] https://github.com/tbenthompson/cppimport\n\n\n\n.. _cmake:\n\nBuilding with CMake\n===================\n\nFor C++ codebases that have an existing CMake-based build system, a Python\nextension module can be created with just a few lines of code, as seen above in\nthe module section. Pybind11 currently defaults to the old mechanism, though be\naware that CMake 3.27 removed the old mechanism, so pybind11 will automatically\nswitch if the old mechanism is not available. Please opt into the new mechanism\nif at all possible. Our default may change in future versions. This is the\nminimum required:\n\n\n\n.. versionchanged:: 2.6\n CMake 3.4+ is required.\n\n.. versionchanged:: 2.11\n CMake 3.5+ is required.\n\n.. versionchanged:: 2.14\n CMake 3.15+ is required.\n\n\nFurther information can be found at :doc:`cmake/index`.\n\npybind11_add_module\n-------------------\n\nTo ease the creation of Python extension modules, pybind11 provides a CMake\nfunction with the following signature:\n\n.. code-block:: cmake\n\n pybind11_add_module( [MODULE | SHARED] [EXCLUDE_FROM_ALL]\n [NO_EXTRAS] [THIN_LTO] [OPT_SIZE] source1 [source2 ...])\n\nThis function behaves very much like CMake's builtin ``add_library`` (in fact,\nit's a wrapper function around that command). It will add a library target\ncalled ```` to be built from the listed source files. In addition, it\nwill take care of all the Python-specific compiler and linker flags as well\nas the OS- and Python-version-specific file extension. The produced target\n```` can be further manipulated with regular CMake commands.\n\n``MODULE`` or ``SHARED`` may be given to specify the type of library. If no\ntype is given, ``MODULE`` is used by default which ensures the creation of a\nPython-exclusive module. Specifying ``SHARED`` will create a more traditional\ndynamic library which can also be linked from elsewhere. ``EXCLUDE_FROM_ALL``\nremoves this target from the default build (see CMake docs for details).\n\nSince pybind11 is a template library, ``pybind11_add_module`` adds compiler\nflags to ensure high quality code generation without bloat arising from long\nsymbol names and duplication of code in different translation units. It\nsets default visibility to *hidden*, which is required for some pybind11\nfeatures and functionality when attempting to load multiple pybind11 modules\ncompiled under different pybind11 versions. It also adds additional flags\nenabling LTO (Link Time Optimization) and strip unneeded symbols. See the\n:ref:`FAQ entry ` for a more detailed explanation. These\nlatter optimizations are never applied in ``Debug`` mode. If ``NO_EXTRAS`` is\ngiven, they will always be disabled, even in ``Release`` mode. However, this\nwill result in code bloat and is generally not recommended.\n\nAs stated above, LTO is enabled by default. Some newer compilers also support\ndifferent flavors of LTO such as `ThinLTO`_. Setting ``THIN_LTO`` will cause\nthe function to prefer this flavor if available. The function falls back to\nregular LTO if ``-flto=thin`` is not available. If\n``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` is set (either ``ON`` or ``OFF``), then\nthat will be respected instead of the built-in flag search.\n\n.. note::\n\n If you want to set the property form on targets or the\n ``CMAKE_INTERPROCEDURAL_OPTIMIZATION_`` versions of this, you should\n still use ``set(CMAKE_INTERPROCEDURAL_OPTIMIZATION OFF)`` (otherwise a\n no-op) to disable pybind11's ipo flags.\n\nThe ``OPT_SIZE`` flag enables size-based optimization equivalent to the\nstandard ``/Os`` or ``-Os`` compiler flags and the ``MinSizeRel`` build type,\nwhich avoid optimizations that can substantially increase the size of the\nresulting binary. This flag is particularly useful in projects that are split\ninto performance-critical parts and associated bindings. In this case, we can\ncompile the project in release mode (and hence, optimize performance globally),\nand specify ``OPT_SIZE`` for the binding target, where size might be the main\nconcern as performance is often less critical here. A ~25% size reduction has\nbeen observed in practice. This flag only changes the optimization behavior at\na per-target level and takes precedence over the global CMake build type\n(``Release``, ``RelWithDebInfo``) except for ``Debug`` builds, where\noptimizations remain disabled.\n\n.. _ThinLTO: http://clang.llvm.org/docs/ThinLTO.html\n\nConfiguration variables\n-----------------------\n\nBy default, pybind11 will compile modules with the compiler default or the\nminimum standard required by pybind11, whichever is higher. You can set the\nstandard explicitly with\n`CMAKE_CXX_STANDARD `_:\n\n.. code-block:: cmake\n\n set(CMAKE_CXX_STANDARD 14 CACHE STRING \"C++ version selection\") # or 11, 14, 17, 20\n set(CMAKE_CXX_STANDARD_REQUIRED ON) # optional, ensure standard is supported\n set(CMAKE_CXX_EXTENSIONS OFF) # optional, keep compiler extensions off\n\nThe variables can also be set when calling CMake from the command line using\nthe ``-D=`` flag. You can also manually set ``CXX_STANDARD``\non a target or use ``target_compile_features`` on your targets - anything that\nCMake supports.\n\nClassic Python support: The target Python version can be selected by setting\n``PYBIND11_PYTHON_VERSION`` or an exact Python installation can be specified\nwith ``PYTHON_EXECUTABLE``. For example:\n\n.. code-block:: bash\n\n cmake -DPYBIND11_PYTHON_VERSION=3.8 ..\n\n # Another method:\n cmake -DPYTHON_EXECUTABLE=/path/to/python ..\n\n # This often is a good way to get the current Python, works in environments:\n cmake -DPYTHON_EXECUTABLE=$(python3 -c \"import sys; print(sys.executable)\") ..\n\n\nfind_package vs. add_subdirectory\n---------------------------------\n\nFor CMake-based projects that don't include the pybind11 repository internally,\nan external installation can be detected through ``find_package(pybind11)``.\nSee the `Config file`_ docstring for details of relevant CMake variables.\n\n.. code-block:: cmake\n\n cmake_minimum_required(VERSION 3.15...4.2)\n project(example LANGUAGES CXX)\n\n find_package(pybind11 REQUIRED)\n pybind11_add_module(example example.cpp)\n\nNote that ``find_package(pybind11)`` will only work correctly if pybind11\nhas been correctly installed on the system, e. g. after downloading or cloning\nthe pybind11 repository :\n\n.. code-block:: bash\n\n # Classic CMake\n cd pybind11\n mkdir build\n cd build\n cmake ..\n make install\n\n # CMake 3.15+\n cd pybind11\n cmake -S . -B build\n cmake --build build -j 2 # Build on 2 cores\n cmake --install build\n\nOnce detected, the aforementioned ``pybind11_add_module`` can be employed as\nbefore. The function usage and configuration variables are identical no matter\nif pybind11 is added as a subdirectory or found as an installed package. You\ncan refer to the same [cmake_example]_ repository for a full sample project\n-- just swap out ``add_subdirectory`` for ``find_package``.\n\n.. _Config file: https://github.com/pybind/pybind11/blob/master/tools/pybind11Config.cmake.in\n\n\n.. _find-python-mode:\n\nFindPython mode\n---------------\n\nModern CMake (3.18.2+ ideal) added a new module called FindPython that had a\nhighly improved search algorithm and modern targets and tools. If you use\nFindPython, pybind11 will detect this and use the existing targets instead:\n\n.. code-block:: cmake\n\n cmake_minimum_required(VERSION 3.15...4.2)\n project(example LANGUAGES CXX)\n\n find_package(Python 3.8 COMPONENTS Interpreter Development REQUIRED)\n find_package(pybind11 CONFIG REQUIRED)\n # or add_subdirectory(pybind11)\n\n pybind11_add_module(example example.cpp)\n\nYou can also use the targets (as listed below) with FindPython. If you define\n``PYBIND11_FINDPYTHON``, pybind11 will perform the FindPython step for you\n(mostly useful when building pybind11's own tests, or as a way to change search\nalgorithms from the CMake invocation, with ``-DPYBIND11_FINDPYTHON=ON``.\n\n.. warning::\n\n If you use FindPython to multi-target Python versions, use the individual\n targets listed below, and avoid targets that directly include Python parts.\n\nThere are `many ways to hint or force a discovery of a specific Python\ninstallation `_),\nsetting ``Python_ROOT_DIR`` may be the most common one (though with\nvirtualenv/venv support, and Conda support, this tends to find the correct\nPython version more often than the old system did).\n\n.. warning::\n\n When the Python libraries (i.e. ``libpythonXX.a`` and ``libpythonXX.so``\n on Unix) are not available, as is the case on a manylinux image, the\n ``Development`` component will not be resolved by ``FindPython``. When not\n using the embedding functionality, CMake 3.18+ allows you to specify\n ``Development.Module`` instead of ``Development`` to resolve this issue.\n\n.. versionadded:: 2.6\n\nAdvanced: interface library targets\n-----------------------------------\n\nPybind11 supports modern CMake usage patterns with a set of interface targets,\navailable in all modes. The targets provided are:\n\n ``pybind11::headers``\n Just the pybind11 headers and minimum compile requirements\n\n ``pybind11::pybind11``\n Python headers + ``pybind11::headers``\n\n ``pybind11::python_link_helper``\n Just the \"linking\" part of pybind11:module\n\n ``pybind11::module``\n Everything for extension modules - ``pybind11::pybind11`` + ``Python::Module`` (FindPython) or ``pybind11::python_link_helper``\n\n ``pybind11::embed``\n Everything for embedding the Python interpreter - ``pybind11::pybind11`` + ``Python::Python`` (FindPython) or Python libs\n\n ``pybind11::lto`` / ``pybind11::thin_lto``\n An alternative to `INTERPROCEDURAL_OPTIMIZATION` for adding link-time optimization.\n\n ``pybind11::windows_extras``\n ``/bigobj`` and ``/mp`` for MSVC.\n\n ``pybind11::opt_size``\n ``/Os`` for MSVC, ``-Os`` for other compilers. Does nothing for debug builds.\n\nTwo helper functions are also provided:\n\n ``pybind11_strip(target)``\n Strips a target (uses ``CMAKE_STRIP`` after the target is built)\n\n ``pybind11_extension(target)``\n Sets the correct extension (with SOABI) for a target.\n\nYou can use these targets to build complex applications. For example, the\n``add_python_module`` function is identical to:\n\n.. code-block:: cmake\n\n cmake_minimum_required(VERSION 3.15...4.2)\n project(example LANGUAGES CXX)\n\n find_package(pybind11 REQUIRED) # or add_subdirectory(pybind11)\n\n add_library(example MODULE main.cpp)\n\n target_link_libraries(example PRIVATE pybind11::module pybind11::lto pybind11::windows_extras)\n\n pybind11_extension(example)\n if(NOT MSVC AND NOT ${CMAKE_BUILD_TYPE} MATCHES Debug|RelWithDebInfo)\n # Strip unnecessary sections of the binary on Linux/macOS\n pybind11_strip(example)\n endif()\n\n set_target_properties(example PROPERTIES CXX_VISIBILITY_PRESET \"hidden\"\n CUDA_VISIBILITY_PRESET \"hidden\")\n\nInstead of setting properties, you can set ``CMAKE_*`` variables to initialize these correctly.\n\n.. warning::\n\n Since pybind11 is a metatemplate library, it is crucial that certain\n compiler flags are provided to ensure high quality code generation. In\n contrast to the ``pybind11_add_module()`` command, the CMake interface\n provides a *composable* set of targets to ensure that you retain flexibility.\n It can be especially important to provide or set these properties; the\n :ref:`FAQ ` contains an explanation on why these are needed.\n\n.. versionadded:: 2.6\n\n.. _nopython-mode:\n\nAdvanced: NOPYTHON mode\n-----------------------\n\nIf you want complete control, you can set ``PYBIND11_NOPYTHON`` to completely\ndisable Python integration (this also happens if you run ``FindPython2`` and\n``FindPython3`` without running ``FindPython``). This gives you complete\nfreedom to integrate into an existing system (like `Scikit-Build's\n`_ ``PythonExtensions``).\n``pybind11_add_module`` and ``pybind11_extension`` will be unavailable, and the\ntargets will be missing any Python specific behavior.\n\n.. versionadded:: 2.6\n\nEmbedding the Python interpreter\n--------------------------------\n\nIn addition to extension modules, pybind11 also supports embedding Python into\na C++ executable or library. In CMake, simply link with the ``pybind11::embed``\ntarget. It provides everything needed to get the interpreter running. The Python\nheaders and libraries are attached to the target. Unlike ``pybind11::module``,\nthere is no need to manually set any additional properties here. For more\ninformation about usage in C++, see :doc:`/advanced/embedding`.\n\n.. code-block:: cmake\n\n cmake_minimum_required(VERSION 3.15...4.2)\n project(example LANGUAGES CXX)\n\n find_package(pybind11 REQUIRED) # or add_subdirectory(pybind11)\n\n add_executable(example main.cpp)\n target_link_libraries(example PRIVATE pybind11::embed)\n\n.. _building_manually:\n\nBuilding manually\n=================\n\npybind11 is a header-only library, hence it is not necessary to link against\nany special libraries and there are no intermediate (magic) translation steps.\n\nOn Linux, you can compile an example such as the one given in\n:ref:`simple_example` using the following command:\n\n.. code-block:: bash\n\n $ c++ -O3 -Wall -shared -std=c++11 -fPIC $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)\n\nThe ``python3 -m pybind11 --includes`` command fetches the include paths for\nboth pybind11 and Python headers. This assumes that pybind11 has been installed\nusing ``pip`` or ``conda``. If it hasn't, you can also manually specify\n``-I /include`` together with the Python includes path\n``python3-config --includes``.\n\nOn macOS: the build command is almost the same but it also requires passing\nthe ``-undefined dynamic_lookup`` flag so as to ignore missing symbols when\nbuilding the module:\n\n.. code-block:: bash\n\n $ c++ -O3 -Wall -shared -std=c++11 -undefined dynamic_lookup $(python3 -m pybind11 --includes) example.cpp -o example$(python3-config --extension-suffix)\n\nIn general, it is advisable to include several additional build parameters\nthat can considerably reduce the size of the created binary. Refer to section\n:ref:`cmake` for a detailed example of a suitable cross-platform CMake-based\nbuild system that works on all platforms including Windows.\n\n.. note::\n\n On Linux and macOS, it's better to (intentionally) not link against\n ``libpython``. The symbols will be resolved when the extension library\n is loaded into a Python binary. This is preferable because you might\n have several different installations of a given Python version (e.g. the\n system-provided Python, and one that ships with a piece of commercial\n software). In this way, the plugin will work with both versions, instead\n of possibly importing a second Python library into a process that already\n contains one (which will lead to a segfault).\n\n\nBuilding with Bazel\n===================\n\nYou can build with the Bazel build system using the `pybind11_bazel\n`_ repository.\n\nBuilding with Meson\n===================\n\nYou can use Meson, which has support for ``pybind11`` as a dependency (internally\nrelying on our ``pkg-config`` support). See the :ref:`module example above `.\n\n\nGenerating binding code automatically\n=====================================\n\nThe ``Binder`` project is a tool for automatic generation of pybind11 binding\ncode by introspecting existing C++ codebases using LLVM/Clang. See the\n[binder]_ documentation for details.\n\n.. [binder] http://cppbinder.readthedocs.io/en/latest/about.html\n\n[AutoWIG]_ is a Python library that wraps automatically compiled libraries into\nhigh-level languages. It parses C++ code using LLVM/Clang technologies and\ngenerates the wrappers using the Mako templating engine. The approach is automatic,\nextensible, and applies to very complex C++ libraries, composed of thousands of\nclasses or incorporating modern meta-programming constructs.\n\n.. [AutoWIG] https://github.com/StatisKit/AutoWIG\n\n[semiwrap]_ is a build tool that makes it simpler to wrap C/C++ libraries with\npybind11 by automating large portions of the wrapping process and handling some\nof the more complex aspects of creating pybind11 based wrappers (especially with\ntrampolines to allow inheriting from C++ classes from Python). It includes a\nhatchling plugin that autogenerates meson.build files that can be built using\nmeson, and those build files parse your wrapped headers and generate/compile\npybind11 based wrappers into python extension modules.\n\n.. [semiwrap] https://semiwrap.readthedocs.io\n\n[litgen]_ is an automatic python bindings generator with a focus on generating\ndocumented and discoverable bindings: bindings will nicely reproduce the documentation\nfound in headers. It is based on srcML (srcml.org), a highly scalable, multi-language\nparsing tool with a developer centric approach. The API that you want to expose to python\nmust be C++14 compatible (but your implementation can use more modern constructs).\n\n.. [litgen] https://pthom.github.io/litgen\n" }, { "path": "docs/conf.py", "content": "#!/usr/bin/env python3\n#\n# pybind11 documentation build configuration file, created by\n# sphinx-quickstart on Sun Oct 11 19:23:48 2015.\n#\n# This file is execfile()d with the current directory set to its\n# containing dir.\n#\n# Note that not all possible configuration values are present in this\n# autogenerated file.\n#\n# All configuration values have a default; values that are commented out\n# serve to show the default.\nfrom __future__ import annotations\n\nimport os\nimport re\nimport subprocess\nimport sys\nfrom pathlib import Path\n\nDIR = Path(__file__).parent.resolve()\n\n# If extensions (or modules to document with autodoc) are in another directory,\n# add these directories to sys.path here. If the directory is relative to the\n# documentation root, use os.path.abspath to make it absolute, like shown here.\n# sys.path.insert(0, os.path.abspath('.'))\n\n# -- General configuration ------------------------------------------------\n\n# If your documentation needs a minimal Sphinx version, state it here.\n# needs_sphinx = '1.0'\n\n# Add any Sphinx extension module names here, as strings. They can be\n# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom\n# ones.\nextensions = [\n \"breathe\",\n \"myst_parser\",\n \"sphinx_copybutton\",\n \"sphinxcontrib.rsvgconverter\",\n \"sphinxcontrib.moderncmakedomain\",\n]\n\nbreathe_projects = {\"pybind11\": \".build/doxygenxml/\"}\nbreathe_default_project = \"pybind11\"\nbreathe_domain_by_extension = {\"h\": \"cpp\"}\n\n# Add any paths that contain templates here, relative to this directory.\ntemplates_path = [\".templates\"]\n\n# The suffix(es) of source filenames.\nsource_suffix = [\".rst\", \".md\"]\n\n# The encoding of source files.\n# source_encoding = 'utf-8-sig'\n\n# The master toctree document.\nmaster_doc = \"index\"\n\n# General information about the project.\nproject = \"pybind11\"\ncopyright = \"2017, Wenzel Jakob\"\nauthor = \"Wenzel Jakob\"\n\n# The version info for the project you're documenting, acts as replacement for\n# |version| and |release|, also used in various other places throughout the\n# built documents.\n\n# Read the listed version\nversion_file = DIR.parent / \"pybind11/_version.py\"\nwith version_file.open(encoding=\"utf-8\") as f:\n code = compile(f.read(), version_file, \"exec\")\nloc = {\"__file__\": str(version_file)}\nexec(code, loc)\n\n# The full version, including alpha/beta/rc tags.\nversion = loc[\"__version__\"]\n\n# The language for content autogenerated by Sphinx. Refer to documentation\n# for a list of supported languages.\n#\n# This is also used if you do content translation via gettext catalogs.\n# Usually you set \"language\" from the command line for these cases.\nlanguage = \"en\"\n\n# There are two options for replacing |today|: either, you set today to some\n# non-false value, then it is used:\n# today = ''\n# Else, today_fmt is used as the format for a strftime call.\n# today_fmt = '%B %d, %Y'\n\n# List of patterns, relative to source directory, that match files and\n# directories to ignore when looking for source files.\nexclude_patterns = [\".build\", \"release.rst\"]\n\n# The reST default role (used for this markup: `text`) to use for all\n# documents.\ndefault_role = \"any\"\n\n# If true, '()' will be appended to :func: etc. cross-reference text.\n# add_function_parentheses = True\n\n# If true, the current module name will be prepended to all description\n# unit titles (such as .. function::).\n# add_module_names = True\n\n# If true, sectionauthor and moduleauthor directives will be shown in the\n# output. They are ignored by default.\n# show_authors = False\n\n# The name of the Pygments (syntax highlighting) style to use.\n# pygments_style = 'monokai'\n\n# A list of ignored prefixes for module index sorting.\n# modindex_common_prefix = []\n\n# If true, keep warnings as \"system message\" paragraphs in the built documents.\n# keep_warnings = False\n\n# If true, `todo` and `todoList` produce output, else they produce nothing.\ntodo_include_todos = False\n\n\n# -- Options for HTML output ----------------------------------------------\n\n# The theme to use for HTML and HTML Help pages. See the documentation for\n# a list of builtin themes.\n\nhtml_theme = \"furo\"\n\n# Theme options are theme-specific and customize the look and feel of a theme\n# further. For a list of options available for each theme, see the\n# documentation.\n# html_theme_options = {}\n\n# Add any paths that contain custom themes here, relative to this directory.\n# html_theme_path = []\n\n# The name for this set of Sphinx documents. If None, it defaults to\n# \" v documentation\".\n# html_title = None\n\n# A shorter title for the navigation bar. Default is the same as html_title.\n# html_short_title = None\n\n# The name of an image file (relative to this directory) to place at the top\n# of the sidebar.\n# html_logo = None\n\n# The name of an image file (within the static path) to use as favicon of the\n# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32\n# pixels large.\n# html_favicon = None\n\n# Add any paths that contain custom static files (such as style sheets) here,\n# relative to this directory. They are copied after the builtin static files,\n# so a file named \"default.css\" will overwrite the builtin \"default.css\".\nhtml_static_path = [\"_static\"]\n\nhtml_css_files = [\n \"css/custom.css\",\n]\n\n# Add any extra paths that contain custom files (such as robots.txt or\n# .htaccess) here, relative to this directory. These files are copied\n# directly to the root of the documentation.\n# html_extra_path = []\n\n# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,\n# using the given strftime format.\n# html_last_updated_fmt = '%b %d, %Y'\n\n# If true, SmartyPants will be used to convert quotes and dashes to\n# typographically correct entities.\n# html_use_smartypants = True\n\n# Custom sidebar templates, maps document names to template names.\n# html_sidebars = {}\n\n# Additional templates that should be rendered to pages, maps page names to\n# template names.\n# html_additional_pages = {}\n\n# If false, no module index is generated.\n# html_domain_indices = True\n\n# If false, no index is generated.\n# html_use_index = True\n\n# If true, the index is split into individual pages for each letter.\n# html_split_index = False\n\n# If true, links to the reST sources are added to the pages.\n# html_show_sourcelink = True\n\n# If true, \"Created using Sphinx\" is shown in the HTML footer. Default is True.\n# html_show_sphinx = True\n\n# If true, \"(C) Copyright ...\" is shown in the HTML footer. Default is True.\n# html_show_copyright = True\n\n# If true, an OpenSearch description file will be output, and all pages will\n# contain a tag referring to it. The value of this option must be the\n# base URL from which the finished HTML is served.\n# html_use_opensearch = ''\n\n# This is the file name suffix for HTML files (e.g. \".xhtml\").\n# html_file_suffix = None\n\n# Language to be used for generating the HTML full-text search index.\n# Sphinx supports the following languages:\n# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'\n# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'\n# html_search_language = 'en'\n\n# A dictionary with options for the search language support, empty by default.\n# Now only 'ja' uses this config value\n# html_search_options = {'type': 'default'}\n\n# The name of a javascript file (relative to the configuration directory) that\n# implements a search results scorer. If empty, the default will be used.\n# html_search_scorer = 'scorer.js'\n\n# Output file base name for HTML help builder.\nhtmlhelp_basename = \"pybind11doc\"\n\n# -- Options for LaTeX output ---------------------------------------------\n\nlatex_engine = \"pdflatex\"\n\nlatex_elements = {\n # The paper size ('letterpaper' or 'a4paper').\n # 'papersize': 'letterpaper',\n #\n # The font size ('10pt', '11pt' or '12pt').\n # 'pointsize': '10pt',\n #\n # Additional stuff for the LaTeX preamble.\n # remove blank pages (between the title page and the TOC, etc.)\n \"classoptions\": \",openany,oneside\",\n \"preamble\": r\"\"\"\n\\usepackage{fontawesome}\n\\usepackage{textgreek}\n\\DeclareUnicodeCharacter{00A0}{}\n\\DeclareUnicodeCharacter{2194}{\\faArrowsH}\n\\DeclareUnicodeCharacter{1F382}{\\faBirthdayCake}\n\\DeclareUnicodeCharacter{1F355}{\\faAdjust}\n\\DeclareUnicodeCharacter{0301}{'}\n\\DeclareUnicodeCharacter{03C0}{\\textpi}\n\n\"\"\",\n # Latex figure (float) alignment\n # 'figure_align': 'htbp',\n}\n\n# Grouping the document tree into LaTeX files. List of tuples\n# (source start file, target name, title,\n# author, documentclass [howto, manual, or own class]).\nlatex_documents = [\n (master_doc, \"pybind11.tex\", \"pybind11 Documentation\", \"Wenzel Jakob\", \"manual\"),\n]\n\n# The name of an image file (relative to this directory) to place at the top of\n# the title page.\n# latex_logo = 'pybind11-logo.png'\n\n# For \"manual\" documents, if this is true, then toplevel headings are parts,\n# not chapters.\n# latex_use_parts = False\n\n# If true, show page references after internal links.\n# latex_show_pagerefs = False\n\n# If true, show URL addresses after external links.\n# latex_show_urls = False\n\n# Documents to append as an appendix to all manuals.\n# latex_appendices = []\n\n# If false, no module index is generated.\n# latex_domain_indices = True\n\n\n# -- Options for manual page output ---------------------------------------\n\n# One entry per manual page. List of tuples\n# (source start file, name, description, authors, manual section).\nman_pages = [(master_doc, \"pybind11\", \"pybind11 Documentation\", [author], 1)]\n\n# If true, show URL addresses after external links.\n# man_show_urls = False\n\n\n# -- Options for Texinfo output -------------------------------------------\n\n# Grouping the document tree into Texinfo files. List of tuples\n# (source start file, target name, title, author,\n# dir menu entry, description, category)\ntexinfo_documents = [\n (\n master_doc,\n \"pybind11\",\n \"pybind11 Documentation\",\n author,\n \"pybind11\",\n \"One line description of project.\",\n \"Miscellaneous\",\n ),\n]\n\n# Documents to append as an appendix to all manuals.\n# texinfo_appendices = []\n\n# If false, no module index is generated.\n# texinfo_domain_indices = True\n\n# How to display URL addresses: 'footnote', 'no', or 'inline'.\n# texinfo_show_urls = 'footnote'\n\n# If true, do not generate a @detailmenu in the \"Top\" node's menu.\n# texinfo_no_detailmenu = False\n\nprimary_domain = \"cpp\"\nhighlight_language = \"cpp\"\n\n\ndef generate_doxygen_xml(app):\n build_dir = os.path.join(app.confdir, \".build\")\n if not os.path.exists(build_dir):\n os.mkdir(build_dir)\n\n try:\n subprocess.call([\"doxygen\", \"--version\"])\n retcode = subprocess.call([\"doxygen\"], cwd=app.confdir)\n if retcode < 0:\n sys.stderr.write(f\"doxygen error code: {-retcode}\\n\")\n except OSError as e:\n sys.stderr.write(f\"doxygen execution failed: {e}\\n\")\n\n\ndef prepare(app):\n with open(DIR.parent / \"README.rst\") as f:\n contents = f.read()\n\n if app.builder.name == \"latex\":\n # Remove badges and stuff from start\n contents = contents[contents.find(r\".. start\") :]\n\n # Filter out section titles for index.rst for LaTeX\n contents = re.sub(r\"^(.*)\\n[-~]{3,}$\", r\"**\\1**\", contents, flags=re.MULTILINE)\n\n with open(DIR / \"readme.rst\", \"w\") as f:\n f.write(contents)\n\n\ndef clean_up(app, exception): # noqa: ARG001\n (DIR / \"readme.rst\").unlink()\n\n\ndef setup(app):\n # Add hook for building doxygen xml when needed\n app.connect(\"builder-inited\", generate_doxygen_xml)\n\n # Copy the readme in\n app.connect(\"builder-inited\", prepare)\n\n # Clean up the generated readme\n app.connect(\"build-finished\", clean_up)\n" }, { "path": "docs/faq.rst", "content": "Frequently asked questions\n##########################\n\n\"ImportError: dynamic module does not define init function\"\n===========================================================\n\n1. Make sure that the name specified in PYBIND11_MODULE is identical to the\nfilename of the extension library (without suffixes such as ``.so``).\n\n2. If the above did not fix the issue, you are likely using an incompatible\nversion of Python that does not match what you compiled with.\n\n\"Symbol not found: ``__Py_ZeroStruct`` / ``_PyInstanceMethod_Type``\"\n========================================================================\n\nSee the first answer.\n\n\"SystemError: dynamic module not initialized properly\"\n======================================================\n\nSee the first answer.\n\nThe Python interpreter immediately crashes when importing my module\n===================================================================\n\nSee the first answer.\n\n.. _faq_reference_arguments:\n\nLimitations involving reference arguments\n=========================================\n\nIn C++, it's fairly common to pass arguments using mutable references or\nmutable pointers, which allows both read and write access to the value\nsupplied by the caller. This is sometimes done for efficiency reasons, or to\nrealize functions that have multiple return values. Here are two very basic\nexamples:\n\n.. code-block:: cpp\n\n void increment(int &i) { i++; }\n void increment_ptr(int *i) { (*i)++; }\n\nIn Python, all arguments are passed by reference, so there is no general\nissue in binding such code from Python.\n\nHowever, certain basic Python types (like ``str``, ``int``, ``bool``,\n``float``, etc.) are **immutable**. This means that the following attempt\nto port the function to Python doesn't have the same effect on the value\nprovided by the caller -- in fact, it does nothing at all.\n\n.. code-block:: python\n\n def increment(i):\n i += 1 # nope..\n\npybind11 is also affected by such language-level conventions, which means that\nbinding ``increment`` or ``increment_ptr`` will also create Python functions\nthat don't modify their arguments.\n\nAlthough inconvenient, one workaround is to encapsulate the immutable types in\na custom type that does allow modifications.\n\nAn other alternative involves binding a small wrapper lambda function that\nreturns a tuple with all output arguments (see the remainder of the\ndocumentation for examples on binding lambda functions). An example:\n\n.. code-block:: cpp\n\n int foo(int &i) { i++; return 123; }\n\nand the binding code\n\n.. code-block:: cpp\n\n m.def(\"foo\", [](int i) { int rv = foo(i); return std::make_tuple(rv, i); });\n\n\nHow can I reduce the build time?\n================================\n\nIt's good practice to split binding code over multiple files, as in the\nfollowing example:\n\n:file:`example.cpp`:\n\n.. code-block:: cpp\n\n void init_ex1(py::module_ &);\n void init_ex2(py::module_ &);\n /* ... */\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n init_ex1(m);\n init_ex2(m);\n /* ... */\n }\n\n:file:`ex1.cpp`:\n\n.. code-block:: cpp\n\n void init_ex1(py::module_ &m) {\n m.def(\"add\", [](int a, int b) { return a + b; });\n }\n\n:file:`ex2.cpp`:\n\n.. code-block:: cpp\n\n void init_ex2(py::module_ &m) {\n m.def(\"sub\", [](int a, int b) { return a - b; });\n }\n\n:command:`python`:\n\n.. code-block:: pycon\n\n >>> import example\n >>> example.add(1, 2)\n 3\n >>> example.sub(1, 1)\n 0\n\nAs shown above, the various ``init_ex`` functions should be contained in\nseparate files that can be compiled independently from one another, and then\nlinked together into the same final shared object. Following this approach\nwill:\n\n1. reduce memory requirements per compilation unit.\n\n2. enable parallel builds (if desired).\n\n3. allow for faster incremental builds. For instance, when a single class\n definition is changed, only a subset of the binding code will generally need\n to be recompiled.\n\n\"recursive template instantiation exceeded maximum depth of 256\"\n================================================================\n\nIf you receive an error about excessive recursive template evaluation, try\nspecifying a larger value, e.g. ``-ftemplate-depth=1024`` on GCC/Clang. The\nculprit is generally the generation of function signatures at compile time\nusing C++14 template metaprogramming.\n\n.. _`faq:hidden_visibility`:\n\n\"'SomeClass' declared with greater visibility than the type of its field 'SomeClass::member' [-Wattributes]\"\n============================================================================================================\n\nThis error typically indicates that you are compiling without the required\n``-fvisibility`` flag. pybind11 code internally forces hidden visibility on\nall internal code, but if non-hidden (and thus *exported*) code attempts to\ninclude a pybind type (for example, ``py::object`` or ``py::list``) you can run\ninto this warning.\n\nTo avoid it, make sure you are specifying ``-fvisibility=hidden`` when\ncompiling pybind code.\n\nAs to why ``-fvisibility=hidden`` is necessary, because pybind modules could\nhave been compiled under different versions of pybind itself, it is also\nimportant that the symbols defined in one module do not clash with the\npotentially-incompatible symbols defined in another. While Python extension\nmodules are usually loaded with localized symbols (under POSIX systems\ntypically using ``dlopen`` with the ``RTLD_LOCAL`` flag), this Python default\ncan be changed, but even if it isn't it is not always enough to guarantee\ncomplete independence of the symbols involved when not using\n``-fvisibility=hidden``.\n\nAdditionally, ``-fvisibility=hidden`` can deliver considerably binary size\nsavings. (See the following section for more details.)\n\n\n.. _`faq:symhidden`:\n\nHow can I create smaller binaries?\n==================================\n\nTo do its job, pybind11 extensively relies on a programming technique known as\n*template metaprogramming*, which is a way of performing computation at compile\ntime using type information. Template metaprogramming usually instantiates code\ninvolving significant numbers of deeply nested types that are either completely\nremoved or reduced to just a few instructions during the compiler's optimization\nphase. However, due to the nested nature of these types, the resulting symbol\nnames in the compiled extension library can be extremely long. For instance,\nthe included test suite contains the following symbol:\n\n.. only:: html\n\n .. code-block:: none\n\n _​_​Z​N​8​p​y​b​i​n​d​1​1​1​2​c​p​p​_​f​u​n​c​t​i​o​n​C​1​I​v​8​E​x​a​m​p​l​e​2​J​R​N​S​t​3​_​_​1​6​v​e​c​t​o​r​I​N​S​3​_​1​2​b​a​s​i​c​_​s​t​r​i​n​g​I​w​N​S​3​_​1​1​c​h​a​r​_​t​r​a​i​t​s​I​w​E​E​N​S​3​_​9​a​l​l​o​c​a​t​o​r​I​w​E​E​E​E​N​S​8​_​I​S​A​_​E​E​E​E​E​J​N​S​_​4​n​a​m​e​E​N​S​_​7​s​i​b​l​i​n​g​E​N​S​_​9​i​s​_​m​e​t​h​o​d​E​A​2​8​_​c​E​E​E​M​T​0​_​F​T​_​D​p​T​1​_​E​D​p​R​K​T​2​_\n\n.. only:: not html\n\n .. code-block:: cpp\n\n __ZN8pybind1112cpp_functionC1Iv8Example2JRNSt3__16vectorINS3_12basic_stringIwNS3_11char_traitsIwEENS3_9allocatorIwEEEENS8_ISA_EEEEEJNS_4nameENS_7siblingENS_9is_methodEA28_cEEEMT0_FT_DpT1_EDpRKT2_\n\nwhich is the mangled form of the following function type:\n\n.. code-block:: cpp\n\n pybind11::cpp_function::cpp_function, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >&, pybind11::name, pybind11::sibling, pybind11::is_method, char [28]>(void (Example2::*)(std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >&), pybind11::name const&, pybind11::sibling const&, pybind11::is_method const&, char const (&) [28])\n\nThe memory needed to store just the mangled name of this function (196 bytes)\nis larger than the actual piece of code (111 bytes) it represents! On the other\nhand, it's silly to even give this function a name -- after all, it's just a\ntiny cog in a bigger piece of machinery that is not exposed to the outside\nworld. So we'll generally only want to export symbols for those functions which\nare actually called from the outside.\n\nThis can be achieved by specifying the parameter ``-fvisibility=hidden`` to GCC\nand Clang, which sets the default symbol visibility to *hidden*, which has a\ntremendous impact on the final binary size of the resulting extension library.\n(On Visual Studio, symbols are already hidden by default, so nothing needs to\nbe done there.)\n\nIn addition to decreasing binary size, ``-fvisibility=hidden`` also avoids\npotential serious issues when loading multiple modules and is required for\nproper pybind operation. See the previous FAQ entry for more details.\n\nHow can I properly handle Ctrl-C in long-running functions?\n===========================================================\n\nCtrl-C is received by the Python interpreter, and holds it until the GIL\nis released, so a long-running function won't be interrupted.\n\nTo interrupt from inside your function, you can use the ``PyErr_CheckSignals()``\nfunction, that will tell if a signal has been raised on the Python side. This\nfunction merely checks a flag, so its impact is negligible. When a signal has\nbeen received, you must either explicitly interrupt execution by throwing\n``py::error_already_set`` (which will propagate the existing\n``KeyboardInterrupt``), or clear the error (which you usually will not want):\n\n.. code-block:: cpp\n\n PYBIND11_MODULE(example, m, py::mod_gil_not_used()) {\n m.def(\"long running_func\", []()\n {\n for (;;) {\n if (PyErr_CheckSignals() != 0)\n throw py::error_already_set();\n // Long running iteration\n }\n });\n }\n\nWhat is a highly conclusive and simple way to find memory leaks (e.g. in pybind11 bindings)?\n============================================================================================\n\nUse ``while True`` & ``top`` (Linux, macOS).\n\nFor example, locally change tests/test_type_caster_pyobject_ptr.py like this:\n\n.. code-block:: diff\n\n def test_return_list_pyobject_ptr_reference():\n + while True:\n vec_obj = m.return_list_pyobject_ptr_reference(ValueHolder)\n assert [e.value for e in vec_obj] == [93, 186]\n # Commenting out the next `assert` will leak the Python references.\n # An easy way to see evidence of the leaks:\n # Insert `while True:` as the first line of this function and monitor the\n # process RES (Resident Memory Size) with the Unix top command.\n - assert m.dec_ref_each_pyobject_ptr(vec_obj) == 2\n + # assert m.dec_ref_each_pyobject_ptr(vec_obj) == 2\n\nThen run the test as you would normally do, which will go into the infinite loop.\n\n**In another shell, but on the same machine** run:\n\n.. code-block:: bash\n\n top\n\nThis will show:\n\n.. code-block::\n\n PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND\n 1266095 rwgk 20 0 5207496 611372 45696 R 100.0 0.3 0:08.01 test_type_caste\n\nLook for the number under ``RES`` there. You'll see it going up very quickly.\n\n**Don't forget to Ctrl-C the test command** before your machine becomes\nunresponsive due to swapping.\n\nThis method only takes a couple minutes of effort and is very conclusive.\nWhat you want to see is that the ``RES`` number is stable after a couple\nseconds.\n\nCMake doesn't detect the right Python version\n=============================================\n\nThe CMake-based build system will try to automatically detect the installed\nversion of Python and link against that. When this fails, or when there are\nmultiple versions of Python and it finds the wrong one, delete\n``CMakeCache.txt`` and then add ``-DPYTHON_EXECUTABLE=$(which python)`` to your\nCMake configure line. (Replace ``$(which python)`` with a path to python if\nyour prefer.)\n\nYou can alternatively try ``-DPYBIND11_FINDPYTHON=ON``, which will activate the\nnew CMake FindPython support instead of pybind11's custom search. Newer CMake,\nlike, 3.18.2+, is recommended. You can set this in your ``CMakeLists.txt``\nbefore adding or finding pybind11, as well.\n\nInconsistent detection of Python version in CMake and pybind11\n==============================================================\n\nThe functions ``find_package(PythonInterp)`` and ``find_package(PythonLibs)``\nprovided by CMake for Python version detection are modified by pybind11 due to\nunreliability and limitations that make them unsuitable for pybind11's needs.\nInstead pybind11 provides its own, more reliable Python detection CMake code.\nConflicts can arise, however, when using pybind11 in a project that *also* uses\nthe CMake Python detection in a system with several Python versions installed.\n\nThis difference may cause inconsistencies and errors if *both* mechanisms are\nused in the same project.\n\nThere are three possible solutions:\n\n1. Avoid using ``find_package(PythonInterp)`` and ``find_package(PythonLibs)``\n from CMake and rely on pybind11 in detecting Python version. If this is not\n possible, the CMake machinery should be called *before* including pybind11.\n2. Set ``PYBIND11_FINDPYTHON`` to ``True`` or use ``find_package(Python\n COMPONENTS Interpreter Development)`` on modern CMake ( 3.18.2+ best).\n Pybind11 in these cases uses the new CMake FindPython instead of the old,\n deprecated search tools, and these modules are much better at finding the\n correct Python. If FindPythonLibs/Interp are not available (CMake 3.27+),\n then this will be ignored and FindPython will be used.\n3. Set ``PYBIND11_NOPYTHON`` to ``TRUE``. Pybind11 will not search for Python.\n However, you will have to use the target-based system, and do more setup\n yourself, because it does not know about or include things that depend on\n Python, like ``pybind11_add_module``. This might be ideal for integrating\n into an existing system, like scikit-build's Python helpers.\n\nHow to cite this project?\n=========================\n\nWe suggest the following BibTeX template to cite pybind11 in scientific\ndiscourse:\n\n.. code-block:: bash\n\n @misc{pybind11,\n author = {Wenzel Jakob and Jason Rhinelander and Dean Moldovan},\n year = {2017},\n note = {https://github.com/pybind/pybind11},\n title = {pybind11 -- Seamless operability between C++11 and Python}\n }\n" }, { "path": "docs/index.rst", "content": ".. only:: latex\n\n Intro\n =====\n\n.. include:: readme.rst\n\n.. only:: not latex\n\n Contents:\n\n.. toctree::\n :maxdepth: 1\n\n changelog\n upgrade\n\n.. toctree::\n :caption: The Basics\n :maxdepth: 2\n\n installing\n basics\n classes\n compiling\n\n.. toctree::\n :caption: Advanced Topics\n :maxdepth: 2\n\n advanced/functions\n advanced/classes\n advanced/exceptions\n advanced/smart_ptrs\n advanced/cast/index\n advanced/pycpp/index\n advanced/embedding\n advanced/misc\n advanced/deprecated\n\n.. toctree::\n :caption: Extra Information\n :maxdepth: 1\n\n faq\n benchmark\n limitations\n reference\n cmake/index\n" }, { "path": "docs/installing.rst", "content": ".. _installing:\n\nInstalling the library\n######################\n\nThere are several ways to get the pybind11 source, which lives at\n`pybind/pybind11 on GitHub `_. The pybind11\ndevelopers recommend one of the first three ways listed here, submodule, PyPI,\nor conda-forge, for obtaining pybind11.\n\n.. _include_as_a_submodule:\n\nInclude as a submodule\n======================\n\nWhen you are working on a project in Git, you can use the pybind11 repository\nas a submodule. From your git repository, use:\n\n.. code-block:: bash\n\n git submodule add -b stable ../../pybind/pybind11 extern/pybind11\n git submodule update --init\n\nThis assumes you are placing your dependencies in ``extern/``, and that you are\nusing GitHub; if you are not using GitHub, use the full https or ssh URL\ninstead of the relative URL ``../../pybind/pybind11`` above. Some other servers\nalso require the ``.git`` extension (GitHub does not).\n\nFrom here, you can now include ``extern/pybind11/include``, or you can use\nthe various integration tools (see :ref:`compiling`) pybind11 provides directly\nfrom the local folder.\n\nInclude with PyPI\n=================\n\nYou can download the sources and CMake files as a Python package from PyPI\nusing Pip. Just use:\n\n.. code-block:: bash\n\n pip install pybind11\n\nThis will provide pybind11 in a standard Python package format. If you want\npybind11 available directly in your environment root, you can use:\n\n.. code-block:: bash\n\n pip install \"pybind11[global]\"\n\nThis is not recommended if you are installing with your system Python, as it\nwill add files to ``/usr/local/include/pybind11`` and\n``/usr/local/share/cmake/pybind11``, so unless that is what you want, it is\nrecommended only for use in virtual environments or your ``pyproject.toml``\nfile (see :ref:`compiling`).\n\nInclude with conda-forge\n========================\n\nYou can use pybind11 with conda packaging via `conda-forge\n`_:\n\n.. code-block:: bash\n\n conda install -c conda-forge pybind11\n\n\nInclude with vcpkg\n==================\nYou can download and install pybind11 using the Microsoft `vcpkg\n`_ dependency manager:\n\n.. code-block:: bash\n\n git clone https://github.com/Microsoft/vcpkg.git\n cd vcpkg\n ./bootstrap-vcpkg.sh\n ./vcpkg integrate install\n vcpkg install pybind11\n\nThe pybind11 port in vcpkg is kept up to date by Microsoft team members and\ncommunity contributors. If the version is out of date, please `create an issue\nor pull request `_ on the vcpkg\nrepository.\n\nGlobal install with brew\n========================\n\nThe brew package manager (Homebrew on macOS, or Linuxbrew on Linux) has a\n`pybind11 package\n`_.\nTo install:\n\n.. code-block:: bash\n\n brew install pybind11\n\n.. We should list Conan, and possibly a few other C++ package managers (hunter,\n.. perhaps). Conan has a very clean CMake integration that would be good to show.\n\nOther options\n=============\n\nOther locations you can find pybind11 are `listed here\n`_; these are maintained\nby various packagers and the community.\n" }, { "path": "docs/limitations.rst", "content": "Limitations\n###########\n\nDesign choices\n^^^^^^^^^^^^^^\n\npybind11 strives to be a general solution to binding generation, but it also has\ncertain limitations:\n\n- pybind11 casts away ``const``-ness in function arguments and return values.\n This is in line with the Python language, which has no concept of ``const``\n values. This means that some additional care is needed to avoid bugs that\n would be caught by the type checker in a traditional C++ program.\n\n- The NumPy interface ``pybind11::array`` greatly simplifies accessing\n numerical data from C++ (and vice versa), but it's not a full-blown array\n class like ``Eigen::Array`` or ``boost.multi_array``. ``Eigen`` objects are\n directly supported, however, with ``pybind11/eigen.h``.\n\nLarge but useful features could be implemented in pybind11 but would lead to a\nsignificant increase in complexity. Pybind11 strives to be simple and compact.\nUsers who require large new features are encouraged to write an extension to\npybind11; see `pybind11_json `_ for an\nexample.\n\n\nKnown bugs\n^^^^^^^^^^\n\nThese are issues that hopefully will one day be fixed, but currently are\nunsolved. If you know how to help with one of these issues, contributions\nare welcome!\n\n- Intel 20.2 is currently having an issue with the test suite.\n `#2573 `_\n\n- Debug mode Python does not support 1-5 tests in the test suite currently.\n `#2422 `_\n\n- PyPy3 7.3.1 and 7.3.2 have issues with several tests on 32-bit Windows.\n\nKnown limitations\n^^^^^^^^^^^^^^^^^\n\nThese are issues that are probably solvable, but have not been fixed yet. A\nclean, well written patch would likely be accepted to solve them.\n\n- Type casters are not kept alive recursively.\n `#2527 `_\n One consequence is that containers of ``char *`` are currently not supported.\n `#2245 `_\n\nPython 3.9.0 warning\n^^^^^^^^^^^^^^^^^^^^\n\nCombining older versions of pybind11 (< 2.6.0) with Python on exactly 3.9.0\nwill trigger undefined behavior that typically manifests as crashes during\ninterpreter shutdown (but could also destroy your data. **You have been\nwarned**).\n\nThis issue was `fixed in Python `_.\nAs a mitigation for this bug, pybind11 2.6.0 or newer includes a workaround\nspecifically when Python 3.9.0 is detected at runtime, leaking about 50 bytes\nof memory when a callback function is garbage collected. For reference, the\npybind11 test suite has about 2,000 such callbacks, but only 49 are garbage\ncollected before the end-of-process. Wheels (even if built with Python 3.9.0)\nwill correctly avoid the leak when run in Python 3.9.1, and this does not\naffect other 3.X versions.\n" }, { "path": "docs/reference.rst", "content": ".. _reference:\n\n.. warning::\n\n Please be advised that the reference documentation discussing pybind11\n internals is currently incomplete. Please refer to the previous sections\n and the pybind11 header files for the nitty gritty details.\n\nReference\n#########\n\n.. _macros:\n\nMacros\n======\n\n.. doxygendefine:: PYBIND11_MODULE\n\n.. _core_types:\n\nConvenience classes for arbitrary Python types\n==============================================\n\nCommon member functions\n-----------------------\n\n.. doxygenclass:: object_api\n :members:\n\nWithout reference counting\n--------------------------\n\n.. doxygenclass:: handle\n :members:\n\nWith reference counting\n-----------------------\n\n.. doxygenclass:: object\n :members:\n\n.. doxygenfunction:: reinterpret_borrow\n\n.. doxygenfunction:: reinterpret_steal\n\nConvenience classes for specific Python types\n=============================================\n\n.. doxygenclass:: module_\n :members:\n\n.. doxygengroup:: pytypes\n :members:\n\nConvenience functions converting to Python types\n================================================\n\n.. doxygenfunction:: make_tuple(Args&&...)\n\n.. doxygenfunction:: make_iterator(Iterator, Sentinel, Extra &&...)\n.. doxygenfunction:: make_iterator(Type &, Extra&&...)\n\n.. doxygenfunction:: make_key_iterator(Iterator, Sentinel, Extra &&...)\n.. doxygenfunction:: make_key_iterator(Type &, Extra&&...)\n\n.. doxygenfunction:: make_value_iterator(Iterator, Sentinel, Extra &&...)\n.. doxygenfunction:: make_value_iterator(Type &, Extra&&...)\n\n.. _extras:\n\nPassing extra arguments to ``def`` or ``py::class_``\n====================================================\n\n.. doxygengroup:: annotations\n :members:\n\nEmbedding the interpreter\n=========================\n\n.. doxygendefine:: PYBIND11_EMBEDDED_MODULE\n\n.. doxygenfunction:: initialize_interpreter\n\n.. doxygenfunction:: finalize_interpreter\n\n.. doxygenclass:: scoped_interpreter\n\nRedirecting C++ streams\n=======================\n\n.. doxygenclass:: scoped_ostream_redirect\n\n.. doxygenclass:: scoped_estream_redirect\n\n.. doxygenfunction:: add_ostream_redirect\n\nPython built-in functions\n=========================\n\n.. doxygengroup:: python_builtins\n :members:\n\nInheritance\n===========\n\nSee :doc:`/classes` and :doc:`/advanced/classes` for more detail.\n\n.. doxygendefine:: PYBIND11_OVERRIDE\n\n.. doxygendefine:: PYBIND11_OVERRIDE_PURE\n\n.. doxygendefine:: PYBIND11_OVERRIDE_NAME\n\n.. doxygendefine:: PYBIND11_OVERRIDE_PURE_NAME\n\n.. doxygenfunction:: get_override\n\nExceptions\n==========\n\n.. doxygenclass:: error_already_set\n :members:\n\n.. doxygenclass:: builtin_exception\n :members:\n\nLiterals\n========\n\n.. doxygennamespace:: literals\n" }, { "path": "docs/release.rst", "content": "On version numbers\n^^^^^^^^^^^^^^^^^^\n\nThe version number must be a valid `PEP 440\n`_ version number.\n\nFor example:\n\n.. code-block:: C++\n\n #define PYBIND11_VERSION_MAJOR X\n #define PYBIND11_VERSION_MINOR Y\n #define PYBIND11_VERSION_MICRO Z\n #define PYBIND11_VERSION_RELEASE_LEVEL PY_RELEASE_LEVEL_ALPHA\n #define PYBIND11_VERSION_RELEASE_SERIAL 0\n #define PYBIND11_VERSION_PATCH Za0\n\nFor beta, ``PYBIND11_VERSION_PATCH`` should be ``Zb1``. RC's can be ``Zrc1``.\nFor a final release, this must be a simple integer.\n\n\nTo release a new version of pybind11:\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIf you don't have nox, you should either use ``pipx run nox`` instead, or use\n``uv tool install nox``, ``pipx install nox``, or ``brew install nox`` (Unix).\n\n- Update the version number\n\n - Update ``PYBIND11_VERSION_MAJOR`` etc. in\n ``include/pybind11/detail/common.h``. MICRO should be a simple integer.\n\n - Run ``nox -s tests_packaging`` to ensure this was done correctly.\n\n- Ensure that all the information in ``pyproject.toml`` is up-to-date, like\n supported Python versions.\n\n- Add release date in ``docs/changelog.md`` and integrate the output of\n ``nox -s make_changelog``.\n\n - Note that the ``nox -s make_changelog`` command inspects\n `needs changelog `_.\n\n - Manually clear the ``needs changelog`` labels using the GitHub web\n interface (very easy: start by clicking the link above).\n\n- ``git add`` and ``git commit``, ``git push``. **Ensure CI passes**. (If it\n fails due to a known flake issue, either ignore or restart CI.)\n\n- Add a release branch if this is a new MINOR version, or update the existing\n release branch if it is a patch version\n\n - NOTE: This documentation assumes your ``upstream`` is ``https://github.com/pybind/pybind11.git``\n\n - New branch: ``git checkout -b vX.Y``, ``git push -u upstream vX.Y``\n\n - Update branch: ``git checkout vX.Y``, ``git merge ``, ``git push``\n\n- Update tags (optional; if you skip this, the GitHub release makes a\n non-annotated tag for you)\n\n - ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``\n\n - ``git grep PYBIND11_VERSION include/pybind11/detail/common.h``\n\n - Last-minute consistency check: same as tag?\n\n - Push the new tag: ``git push upstream vX.Y.Z``\n\n- Update stable\n\n - ``git checkout stable``\n\n - ``git merge -X theirs vX.Y.Z``\n\n - ``git diff vX.Y.Z``\n\n - Carefully review and reconcile any diffs. There should be none.\n\n - ``git push``\n\n- Make a GitHub release (this shows up in the UI, sends new release\n notifications to users watching releases, and also uploads PyPI packages).\n (Note: if you do not use an existing tag, this creates a new lightweight tag\n for you, so you could skip the above step.)\n\n - GUI method: Under `releases `_\n click \"Draft a new release\" on the far right, fill in the tag name\n (if you didn't tag above, it will be made here), fill in a release name\n like \"Version X.Y.Z\", and copy-and-paste the markdown-formatted (!) changelog\n into the description. You can remove line breaks and optionally strip links\n to PRs and issues, e.g. to a bare ``#1234`` without the hyperlink markup.\n Check \"pre-release\" if this is an alpha/beta/RC.\n\n - CLI method: with ``gh`` installed, run ``gh release create vX.Y.Z -t \"Version X.Y.Z\"``\n If this is a pre-release, add ``-p``.\n\n- Get back to work\n\n - Make sure you are on master, not somewhere else: ``git checkout master``\n\n - Update version macros in ``include/pybind11/detail/common.h`` (set PATCH to\n ``0a0`` and increment MINOR).\n\n - Update ``pybind11/_version.py`` to match.\n\n - Run ``nox -s tests_packaging`` to ensure this was done correctly.\n\n - If the release was a new MINOR version, add a new ``IN DEVELOPMENT``\n section in ``docs/changelog.md``.\n\n - ``git add``, ``git commit``, ``git push``\n\nIf a version branch is updated, remember to set PATCH to ``1a0``.\n\nConda-forge should automatically make a PR in a few hours, and automatically\nmerge it if there are no issues. Homebrew should be automatic, too.\n\n\nManual packaging\n^^^^^^^^^^^^^^^^\n\nIf you need to manually upload releases, you can download the releases from\nthe job artifacts and upload them with twine. You can also make the files\nlocally (not recommended in general, as your local directory is more likely\nto be \"dirty\" and SDists love picking up random unrelated/hidden files);\nthis is the procedure:\n\n.. code-block:: bash\n\n nox -s build\n nox -s build_global\n twine upload dist/*\n\nThis makes SDists and wheels, and the final line uploads them.\n" }, { "path": "docs/requirements.in", "content": "breathe\nfuro\nmyst_parser\nsphinx\nsphinx-copybutton\nsphinxcontrib-moderncmakedomain\nsphinxcontrib-svg2pdfconverter\n" }, { "path": "docs/requirements.txt", "content": "# This file was autogenerated by uv via the following command:\n# uv pip compile docs/requirements.in -o docs/requirements.txt\nalabaster==0.7.16\n # via sphinx\nbabel==2.14.0\n # via sphinx\nbeautifulsoup4==4.12.3\n # via furo\nbreathe==4.35.0\n # via -r requirements.in\ncertifi==2024.7.4\n # via requests\ncharset-normalizer==3.3.2\n # via requests\ndocutils==0.20.1\n # via\n # breathe\n # myst-parser\n # sphinx\nfuro==2024.1.29\n # via -r requirements.in\nidna==3.7\n # via requests\nimagesize==1.4.1\n # via sphinx\njinja2==3.1.6\n # via\n # myst-parser\n # sphinx\nmarkdown-it-py==3.0.0\n # via\n # mdit-py-plugins\n # myst-parser\nmarkupsafe==2.1.5\n # via jinja2\nmdit-py-plugins==0.4.2\n # via myst-parser\nmdurl==0.1.2\n # via markdown-it-py\nmyst-parser==3.0.1\n # via -r requirements.in\npackaging==24.0\n # via sphinx\npygments==2.17.2\n # via\n # furo\n # sphinx\npyyaml==6.0.2\n # via myst-parser\nrequests==2.32.4\n # via sphinx\nsnowballstemmer==2.2.0\n # via sphinx\nsoupsieve==2.5\n # via beautifulsoup4\nsphinx==7.2.6\n # via\n # -r requirements.in\n # breathe\n # furo\n # myst-parser\n # sphinx-basic-ng\n # sphinx-copybutton\n # sphinxcontrib-moderncmakedomain\n # sphinxcontrib-svg2pdfconverter\nsphinx-basic-ng==1.0.0b2\n # via furo\nsphinx-copybutton==0.5.2\n # via -r requirements.in\nsphinxcontrib-applehelp==1.0.8\n # via sphinx\nsphinxcontrib-devhelp==1.0.6\n # via sphinx\nsphinxcontrib-htmlhelp==2.0.5\n # via sphinx\nsphinxcontrib-jsmath==1.0.1\n # via sphinx\nsphinxcontrib-moderncmakedomain==3.27.0\n # via -r requirements.in\nsphinxcontrib-qthelp==1.0.7\n # via sphinx\nsphinxcontrib-serializinghtml==1.1.10\n # via sphinx\nsphinxcontrib-svg2pdfconverter==1.2.2\n # via -r requirements.in\nurllib3==2.6.3\n # via requests\n" }, { "path": "docs/upgrade.rst", "content": "Upgrade guide\n#############\n\nThis is a companion guide to the :doc:`changelog`. While the changelog briefly\nlists all of the new features, improvements and bug fixes, this upgrade guide\nfocuses only the subset which directly impacts your experience when upgrading\nto a new version. But it goes into more detail. This includes things like\ndeprecated APIs and their replacements, build system changes, general code\nmodernization and other useful information.\n\n.. _upgrade-guide-3.0:\n\nv3.0\n====\n\npybind11 v3.0 introduces major new features, but the vast majority of\nexisting extensions are expected to build and run without modification. Minor\nadjustments may be needed in rare cases, and any such changes can be easily\nwrapped in preprocessor conditionals to maintain compatibility with the\n2.x series.\n\nHowever, due to new features and modernizations, extensions built with\npybind11 v3.0 are not ABI-compatible with those built using v2.13. To ensure\ncross-extension-module compatibility, it is recommended to rebuild all\npybind11-based extensions with v3.0.\n\nCMake support now defaults to the modern FindPython module. If you haven't\nupdated yet, we provide some backward compatibility for ``PYTHON_*`` variables,\nbut you should switch to using ``Python_*`` variables instead. Note that\nsetting ``PYTHON_*`` variables no longer affects the build.\n\nA major new feature in this release is the integration of\n``py::smart_holder``, which improves support for ``std::unique_ptr``\nand ``std::shared_ptr``, resolving several long-standing issues. See\n:ref:`smart_holder` for details. Closely related is the addition\nof ``py::trampoline_self_life_support``, documented under\n:ref:`overriding_virtuals`.\n\nThis release includes a major modernization of cross-extension-module\nABI compatibility handling. The new implementation reflects actual ABI\ncompatibility much more accurately than in previous versions. The details\nare subtle and complex; see\n`#4953 `_ and\n`#5439 `_.\n\nAlso new in v3.0 is ``py::native_enum``, a modern API for exposing\nC++ enumerations as native Python types — typically standard-library\n``enum.Enum`` or related subclasses. This provides improved integration with\nPython's enum system, compared to the older (now deprecated) ``py::enum_``.\nSee `#5555 `_ for details.\nNote that ``#include `` is not included automatically\nand must be added explicitly.\n\nFunctions exposed with pybind11 are now pickleable. This removes a\nlong-standing obstacle when using pybind11-bound functions with Python features\nthat rely on pickling, such as multiprocessing and caching tools.\nSee `#5580 `_ for details.\n\nAnything producing a deprecation warning in the 2.x series may be removed in a\nfuture minor release of 3.x. Most of these are still present in 3.0 in order to ease\ntransition. The new :ref:`deprecated` page details deprecations.\n\nMigration Recommendations\n-------------------------\n\nWe recommend migrating to pybind11 v3.0 promptly, while keeping initial\nchanges to a minimum. Most projects can upgrade simply by updating the\npybind11 version, without altering existing binding code.\n\nAfter a short stabilization period — enough to surface any subtle issues —\nyou may incrementally adopt new features where appropriate:\n\n* Use ``py::smart_holder`` and ``py::trampoline_self_life_support`` as needed,\n or to improve code health. Note that ``py::classh`` is available as a\n shortcut — for example, ``py::classh`` is shorthand for\n ``py::class_``. This is designed to enable easy\n experimentation with ``py::smart_holder`` without introducing distracting\n whitespace changes. In many cases, a global replacement of ``py::class_``\n with ``py::classh`` can be an effective first step. Build failures will\n quickly identify places where ``std::shared_ptr<...>`` holders need to be\n removed. Runtime failures (assuming good unit test coverage) will highlight\n base-and-derived class situations that require coordinated changes.\n\n Note that ``py::bind_vector`` and ``py::bind_map`` (in pybind11/stl_bind.h)\n have a ``holder_type`` template parameter that defaults to\n ``std::unique_ptr``. If ``py::smart_holder`` functionality is desired or\n required, use e.g. ``py::bind_vector``.\n\n* Gradually migrate from ``py::enum_`` to ``py::native_enum`` to improve\n integration with Python's standard enum types.\n\nThere is no urgency to refactor existing, working bindings — adopt new\nfeatures as the need arises or as part of ongoing maintenance efforts.\n\nIf you are using CMake, update to FindPython variables (mostly changing\nvariables from ``PYTHON_*`` -> ``Python_*``). You should see if you can use\n``set(PYBIND11_FINDPYTHON ON)``, which has been supported for years and will\navoid setting the compatibility mode variables (and will avoid a warning).\n\nPotential stumbling blocks when migrating to v3.0\n-------------------------------------------------\n\nThe following issues are very unlikely to arise, and easy to work around:\n\n* In rare cases, a C++ enum may be bound to Python via a\n :ref:`custom type caster `. In such cases, a\n template specialization like this may be required:\n\n .. code-block:: cpp\n\n #if defined(PYBIND11_HAS_NATIVE_ENUM)\n namespace pybind11::detail {\n template \n struct type_caster_enum_type_enabled<\n FancyEnum,\n enable_if_t::value>> : std::false_type {};\n }\n #endif\n\n This specialization is needed only if the custom type caster is templated.\n\n The ``PYBIND11_HAS_NATIVE_ENUM`` guard is needed only\n if backward compatibility with pybind11v2 is required.\n\n* Similarly, template specializations like the following may be required\n if there are custom\n\n * ``pybind11::detail::copyable_holder_caster`` or\n\n * ``pybind11::detail::move_only_holder_caster``\n\n implementations that are used for ``std::shared_ptr`` or ``std::unique_ptr``\n conversions:\n\n .. code-block:: cpp\n\n #if defined(PYBIND11_HAS_INTERNALS_WITH_SMART_HOLDER_SUPPORT)\n namespace pybind11::detail {\n template \n struct copyable_holder_caster_shared_ptr_with_smart_holder_support_enabled<\n ExampleType,\n enable_if_t::value>> : std::false_type {};\n }\n #endif\n\n .. code-block:: cpp\n\n #if defined(PYBIND11_HAS_INTERNALS_WITH_SMART_HOLDER_SUPPORT)\n namespace pybind11::detail {\n template \n struct move_only_holder_caster_unique_ptr_with_smart_holder_support_enabled<\n ExampleType,\n enable_if_t::value>> : std::false_type {};\n }\n #endif\n\n The ``PYBIND11_HAS_INTERNALS_WITH_SMART_HOLDER_SUPPORT`` guard is needed only\n if backward compatibility with pybind11v2 is required.\n\n (Note that ``copyable_holder_caster`` and ``move_only_holder_caster`` are not\n documented, although they existed since 2017.)\n\n\n.. _upgrade-guide-2.12:\n\nv2.12\n=====\n\nNumPy support has been upgraded to support the 2.x series too. The two relevant\nchanges are that:\n\n* ``dtype.flags()`` is now a ``uint64`` and ``dtype.alignment()`` an\n ``ssize_t`` (and NumPy may return an larger than integer value for\n ``itemsize()`` in NumPy 2.x).\n\n* The long deprecated NumPy function ``PyArray_GetArrayParamsFromObject``\n function is not available anymore.\n\nDue to NumPy changes, you may experience difficulties updating to NumPy 2.\nPlease see the `NumPy 2 migration guide `_\nfor details.\nFor example, a more direct change could be that the default integer ``\"int_\"``\n(and ``\"uint\"``) is now ``ssize_t`` and not ``long`` (affects 64bit windows).\n\nIf you want to only support NumPy 1.x for now and are having problems due to\nthe two internal changes listed above, you can define\n``PYBIND11_NUMPY_1_ONLY`` to disable the new support for now. Make sure you\ndefine this on all pybind11 compile units, since it could be a source of ODR\nviolations if used inconsistently. This option will be removed in the future,\nso adapting your code is highly recommended.\n\n\n.. _upgrade-guide-2.11:\n\nv2.11\n=====\n\n* The minimum version of CMake is now 3.5. A future version will likely move to\n requiring something like CMake 3.15. Note that CMake 3.27 is removing the\n long-deprecated support for ``FindPythonInterp`` if you set 3.27 as the\n minimum or maximum supported version. To prepare for that future, CMake 3.15+\n using ``FindPython`` or setting ``PYBIND11_FINDPYTHON`` is highly recommended,\n otherwise pybind11 will automatically switch to using ``FindPython`` if\n ``FindPythonInterp`` is not available.\n\n\n.. _upgrade-guide-2.9:\n\nv2.9\n====\n\n* Any usage of the recently added ``py::make_simple_namespace`` should be\n converted to using ``py::module_::import(\"types\").attr(\"SimpleNamespace\")``\n instead.\n\n* The use of ``_`` in custom type casters can now be replaced with the more\n readable ``const_name`` instead. The old ``_`` shortcut has been retained\n unless it is being used as a macro (like for gettext).\n\n\n.. _upgrade-guide-2.7:\n\nv2.7\n====\n\n*Before* v2.7, ``py::str`` can hold ``PyUnicodeObject`` or ``PyBytesObject``,\nand ``py::isinstance()`` is ``true`` for both ``py::str`` and\n``py::bytes``. Starting with v2.7, ``py::str`` exclusively holds\n``PyUnicodeObject`` (`#2409 `_),\nand ``py::isinstance()`` is ``true`` only for ``py::str``. To help in\nthe transition of user code, the ``PYBIND11_STR_LEGACY_PERMISSIVE`` macro\nis provided as an escape hatch to go back to the legacy behavior. This macro\nwill be removed in future releases. Two types of required fixes are expected\nto be common:\n\n* Accidental use of ``py::str`` instead of ``py::bytes``, masked by the legacy\n behavior. These are probably very easy to fix, by changing from\n ``py::str`` to ``py::bytes``.\n\n* Reliance on py::isinstance(obj) being ``true`` for\n ``py::bytes``. This is likely to be easy to fix in most cases by adding\n ``|| py::isinstance(obj)``, but a fix may be more involved, e.g. if\n ``py::isinstance`` appears in a template. Such situations will require\n careful review and custom fixes.\n\n\n.. _upgrade-guide-2.6:\n\nv2.6\n====\n\nUsage of the ``PYBIND11_OVERLOAD*`` macros and ``get_overload`` function should\nbe replaced by ``PYBIND11_OVERRIDE*`` and ``get_override``. In the future, the\nold macros may be deprecated and removed.\n\n``py::module`` has been renamed ``py::module_``, but a backward compatible\ntypedef has been included. This change was to avoid a language change in C++20\nthat requires unqualified ``module`` not be placed at the start of a logical\nline. Qualified usage is unaffected and the typedef will remain unless the\nC++ language rules change again.\n\nThe public constructors of ``py::module_`` have been deprecated. Use\n``PYBIND11_MODULE`` or ``module_::create_extension_module`` instead.\n\nAn error is now thrown when ``__init__`` is forgotten on subclasses. This was\nincorrect before, but was not checked. Add a call to ``__init__`` if it is\nmissing.\n\nA ``py::type_error`` is now thrown when casting to a subclass (like\n``py::bytes`` from ``py::object``) if the conversion is not valid. Make a valid\nconversion instead.\n\nThe undocumented ``h.get_type()`` method has been deprecated and replaced by\n``py::type::of(h)``.\n\nEnums now have a ``__str__`` method pre-defined; if you want to override it,\nthe simplest fix is to add the new ``py::prepend()`` tag when defining\n``\"__str__\"``.\n\nIf ``__eq__`` defined but not ``__hash__``, ``__hash__`` is now set to\n``None``, as in normal CPython. You should add ``__hash__`` if you intended the\nclass to be hashable, possibly using the new ``py::hash`` shortcut.\n\nThe constructors for ``py::array`` now always take signed integers for size,\nfor consistency. This may lead to compiler warnings on some systems. Cast to\n``py::ssize_t`` instead of ``std::size_t``.\n\nThe ``tools/clang`` submodule and ``tools/mkdoc.py`` have been moved to a\nstandalone package, `pybind11-mkdoc`_. If you were using those tools, please\nuse them via a pip install from the new location.\n\nThe ``pybind11`` package on PyPI no longer fills the wheel \"headers\" slot - if\nyou were using the headers from this slot, they are available by requesting the\n``global`` extra, that is, ``pip install \"pybind11[global]\"``. (Most users will\nbe unaffected, as the ``pybind11/include`` location is reported by ``python -m\npybind11 --includes`` and ``pybind11.get_include()`` is still correct and has\nnot changed since 2.5).\n\n.. _pybind11-mkdoc: https://github.com/pybind/pybind11-mkdoc\n\nCMake support:\n--------------\n\nThe minimum required version of CMake is now 3.4. Several details of the CMake\nsupport have been deprecated; warnings will be shown if you need to change\nsomething. The changes are:\n\n* ``PYBIND11_CPP_STANDARD=`` is deprecated, please use\n ``CMAKE_CXX_STANDARD=`` instead, or any other valid CMake CXX or CUDA\n standard selection method, like ``target_compile_features``.\n\n* If you do not request a standard, pybind11 targets will compile with the\n compiler default, but not less than C++11, instead of forcing C++14 always.\n If you depend on the old behavior, please use ``set(CMAKE_CXX_STANDARD 14 CACHE STRING \"\")``\n instead.\n\n* Direct ``pybind11::module`` usage should always be accompanied by at least\n ``set(CMAKE_CXX_VISIBILITY_PRESET hidden)`` or similar - it used to try to\n manually force this compiler flag (but not correctly on all compilers or with\n CUDA).\n\n* ``pybind11_add_module``'s ``SYSTEM`` argument is deprecated and does nothing;\n linking now behaves like other imported libraries consistently in both\n config and submodule mode, and behaves like a ``SYSTEM`` library by\n default.\n\n* If ``PYTHON_EXECUTABLE`` is not set, virtual environments (``venv``,\n ``virtualenv``, and ``conda``) are prioritized over the standard search\n (similar to the new FindPython mode).\n\nIn addition, the following changes may be of interest:\n\n* ``CMAKE_INTERPROCEDURAL_OPTIMIZATION`` will be respected by\n ``pybind11_add_module`` if set instead of linking to ``pybind11::lto`` or\n ``pybind11::thin_lto``.\n\n* Using ``find_package(Python COMPONENTS Interpreter Development)`` before\n pybind11 will cause pybind11 to use the new Python mechanisms instead of its\n own custom search, based on a patched version of classic ``FindPythonInterp``\n / ``FindPythonLibs``. In the future, this may become the default. A recent\n (3.15+ or 3.18.2+) version of CMake is recommended.\n\n\n\nv2.5\n====\n\nThe Python package now includes the headers as data in the package itself, as\nwell as in the \"headers\" wheel slot. ``pybind11 --includes`` and\n``pybind11.get_include()`` report the new location, which is always correct\nregardless of how pybind11 was installed, making the old ``user=`` argument\nmeaningless. If you are not using the function to get the location already, you\nare encouraged to switch to the package location.\n\n\nv2.2\n====\n\nDeprecation of the ``PYBIND11_PLUGIN`` macro\n--------------------------------------------\n\n``PYBIND11_MODULE`` is now the preferred way to create module entry points.\nThe old macro emits a compile-time deprecation warning.\n\n.. code-block:: cpp\n\n // old\n PYBIND11_PLUGIN(example) {\n py::module m(\"example\", \"documentation string\");\n\n m.def(\"add\", [](int a, int b) { return a + b; });\n\n return m.ptr();\n }\n\n // new\n PYBIND11_MODULE(example, m) {\n m.doc() = \"documentation string\"; // optional\n\n m.def(\"add\", [](int a, int b) { return a + b; });\n }\n\n\nNew API for defining custom constructors and pickling functions\n---------------------------------------------------------------\n\nThe old placement-new custom constructors have been deprecated. The new approach\nuses ``py::init()`` and factory functions to greatly improve type safety.\n\nPlacement-new can be called accidentally with an incompatible type (without any\ncompiler errors or warnings), or it can initialize the same object multiple times\nif not careful with the Python-side ``__init__`` calls. The new-style custom\nconstructors prevent such mistakes. See :ref:`custom_constructors` for details.\n\n.. code-block:: cpp\n\n // old -- deprecated (runtime warning shown only in debug mode)\n py::class(m, \"Foo\")\n .def(\"__init__\", [](Foo &self, ...) {\n new (&self) Foo(...); // uses placement-new\n });\n\n // new\n py::class(m, \"Foo\")\n .def(py::init([](...) { // Note: no `self` argument\n return new Foo(...); // return by raw pointer\n // or: return std::make_unique(...); // return by holder\n // or: return Foo(...); // return by value (move constructor)\n }));\n\nMirroring the custom constructor changes, ``py::pickle()`` is now the preferred\nway to get and set object state. See :ref:`pickling` for details.\n\n.. code-block:: cpp\n\n // old -- deprecated (runtime warning shown only in debug mode)\n py::class(m, \"Foo\")\n ...\n .def(\"__getstate__\", [](const Foo &self) {\n return py::make_tuple(self.value1(), self.value2(), ...);\n })\n .def(\"__setstate__\", [](Foo &self, py::tuple t) {\n new (&self) Foo(t[0].cast(), ...);\n });\n\n // new\n py::class(m, \"Foo\")\n ...\n .def(py::pickle(\n [](const Foo &self) { // __getstate__\n return py::make_tuple(self.value1(), self.value2(), ...); // unchanged\n },\n [](py::tuple t) { // __setstate__, note: no `self` argument\n return new Foo(t[0].cast(), ...);\n // or: return std::make_unique(...); // return by holder\n // or: return Foo(...); // return by value (move constructor)\n }\n ));\n\nFor both the constructors and pickling, warnings are shown at module\ninitialization time (on import, not when the functions are called).\nThey're only visible when compiled in debug mode. Sample warning:\n\n.. code-block:: none\n\n pybind11-bound class 'mymodule.Foo' is using an old-style placement-new '__init__'\n which has been deprecated. See the upgrade guide in pybind11's docs.\n\n\nStricter enforcement of hidden symbol visibility for pybind11 modules\n---------------------------------------------------------------------\n\npybind11 now tries to actively enforce hidden symbol visibility for modules.\nIf you're using either one of pybind11's :doc:`CMake or Python build systems\n` (the two example repositories) and you haven't been exporting any\nsymbols, there's nothing to be concerned about. All the changes have been done\ntransparently in the background. If you were building manually or relied on\nspecific default visibility, read on.\n\nSetting default symbol visibility to *hidden* has always been recommended for\npybind11 (see :ref:`faq:symhidden`). On Linux and macOS, hidden symbol\nvisibility (in conjunction with the ``strip`` utility) yields much smaller\nmodule binaries. `CPython's extension docs`_ also recommend hiding symbols\nby default, with the goal of avoiding symbol name clashes between modules.\nStarting with v2.2, pybind11 enforces this more strictly: (1) by declaring\nall symbols inside the ``pybind11`` namespace as hidden and (2) by including\nthe ``-fvisibility=hidden`` flag on Linux and macOS (only for extension\nmodules, not for embedding the interpreter).\n\n.. _CPython's extension docs: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module\n\nThe namespace-scope hidden visibility is done automatically in pybind11's\nheaders and it's generally transparent to users. It ensures that:\n\n* Modules compiled with different pybind11 versions don't clash with each other.\n\n* Some new features, like ``py::module_local`` bindings, can work as intended.\n\nThe ``-fvisibility=hidden`` flag applies the same visibility to user bindings\noutside of the ``pybind11`` namespace. It's now set automatic by pybind11's\nCMake and Python build systems, but this needs to be done manually by users\nof other build systems. Adding this flag:\n\n* Minimizes the chances of symbol conflicts between modules. E.g. if two\n unrelated modules were statically linked to different (ABI-incompatible)\n versions of the same third-party library, a symbol clash would be likely\n (and would end with unpredictable results).\n\n* Produces smaller binaries on Linux and macOS, as pointed out previously.\n\nWithin pybind11's CMake build system, ``pybind11_add_module`` has always been\nsetting the ``-fvisibility=hidden`` flag in release mode. From now on, it's\nbeing applied unconditionally, even in debug mode and it can no longer be opted\nout of with the ``NO_EXTRAS`` option. The ``pybind11::module`` target now also\nadds this flag to its interface. The ``pybind11::embed`` target is unchanged.\n\nThe most significant change here is for the ``pybind11::module`` target. If you\nwere previously relying on default visibility, i.e. if your Python module was\ndoubling as a shared library with dependents, you'll need to either export\nsymbols manually (recommended for cross-platform libraries) or factor out the\nshared library (and have the Python module link to it like the other\ndependents). As a temporary workaround, you can also restore default visibility\nusing the CMake code below, but this is not recommended in the long run:\n\n.. code-block:: cmake\n\n target_link_libraries(mymodule PRIVATE pybind11::module)\n\n add_library(restore_default_visibility INTERFACE)\n target_compile_options(restore_default_visibility INTERFACE -fvisibility=default)\n target_link_libraries(mymodule PRIVATE restore_default_visibility)\n\n\nLocal STL container bindings\n----------------------------\n\nPrevious pybind11 versions could only bind types globally -- all pybind11\nmodules, even unrelated ones, would have access to the same exported types.\nHowever, this would also result in a conflict if two modules exported the\nsame C++ type, which is especially problematic for very common types, e.g.\n``std::vector``. :ref:`module_local` were added to resolve this (see\nthat section for a complete usage guide).\n\n``py::class_`` still defaults to global bindings (because these types are\nusually unique across modules), however in order to avoid clashes of opaque\ntypes, ``py::bind_vector`` and ``py::bind_map`` will now bind STL containers\nas ``py::module_local`` if their elements are: builtins (``int``, ``float``,\netc.), not bound using ``py::class_``, or bound as ``py::module_local``. For\nexample, this change allows multiple modules to bind ``std::vector``\nwithout causing conflicts. See :ref:`stl_bind` for more details.\n\nWhen upgrading to this version, if you have multiple modules which depend on\na single global binding of an STL container, note that all modules can still\naccept foreign ``py::module_local`` types in the direction of Python-to-C++.\nThe locality only affects the C++-to-Python direction. If this is needed in\nmultiple modules, you'll need to either:\n\n* Add a copy of the same STL binding to all of the modules which need it.\n\n* Restore the global status of that single binding by marking it\n ``py::module_local(false)``.\n\nThe latter is an easy workaround, but in the long run it would be best to\nlocalize all common type bindings in order to avoid conflicts with\nthird-party modules.\n\n\nNegative strides for Python buffer objects and numpy arrays\n-----------------------------------------------------------\n\nSupport for negative strides required changing the integer type from unsigned\nto signed in the interfaces of ``py::buffer_info`` and ``py::array``. If you\nhave compiler warnings enabled, you may notice some new conversion warnings\nafter upgrading. These can be resolved using ``static_cast``.\n\n\nDeprecation of some ``py::object`` APIs\n---------------------------------------\n\nTo compare ``py::object`` instances by pointer, you should now use\n``obj1.is(obj2)`` which is equivalent to ``obj1 is obj2`` in Python.\nPreviously, pybind11 used ``operator==`` for this (``obj1 == obj2``), but\nthat could be confusing and is now deprecated (so that it can eventually\nbe replaced with proper rich object comparison in a future release).\n\nFor classes which inherit from ``py::object``, ``borrowed`` and ``stolen``\nwere previously available as protected constructor tags. Now the types\nshould be used directly instead: ``borrowed_t{}`` and ``stolen_t{}``\n(`#771 `_).\n\n\nStricter compile-time error checking\n------------------------------------\n\nSome error checks have been moved from run time to compile time. Notably,\nautomatic conversion of ``std::shared_ptr`` is not possible when ``T`` is\nnot directly registered with ``py::class_`` (e.g. ``std::shared_ptr``\nor ``std::shared_ptr>`` are not automatically convertible).\nAttempting to bind a function with such arguments now results in a compile-time\nerror instead of waiting to fail at run time.\n\n``py::init<...>()`` constructor definitions are also stricter and now prevent\nbindings which could cause unexpected behavior:\n\n.. code-block:: cpp\n\n struct Example {\n Example(int &);\n };\n\n py::class_(m, \"Example\")\n .def(py::init()); // OK, exact match\n // .def(py::init()); // compile-time error, mismatch\n\nA non-``const`` lvalue reference is not allowed to bind to an rvalue. However,\nnote that a constructor taking ``const T &`` can still be registered using\n``py::init()`` because a ``const`` lvalue reference can bind to an rvalue.\n\nv2.1\n====\n\nMinimum compiler versions are enforced at compile time\n------------------------------------------------------\n\nThe minimums also apply to v2.0 but the check is now explicit and a compile-time\nerror is raised if the compiler does not meet the requirements:\n\n* GCC >= 4.8\n* clang >= 3.3 (appleclang >= 5.0)\n* MSVC >= 2015u3\n* Intel C++ >= 15.0\n\n\nThe ``py::metaclass`` attribute is not required for static properties\n---------------------------------------------------------------------\n\nBinding classes with static properties is now possible by default. The\nzero-parameter version of ``py::metaclass()`` is deprecated. However, a new\none-parameter ``py::metaclass(python_type)`` version was added for rare\ncases when a custom metaclass is needed to override pybind11's default.\n\n.. code-block:: cpp\n\n // old -- emits a deprecation warning\n py::class_(m, \"Foo\", py::metaclass())\n .def_property_readonly_static(\"foo\", ...);\n\n // new -- static properties work without the attribute\n py::class_(m, \"Foo\")\n .def_property_readonly_static(\"foo\", ...);\n\n // new -- advanced feature, override pybind11's default metaclass\n py::class_(m, \"Bar\", py::metaclass(custom_python_type))\n ...\n\n\nv2.0\n====\n\nBreaking changes in ``py::class_``\n----------------------------------\n\nThese changes were necessary to make type definitions in pybind11\nfuture-proof, to support PyPy via its ``cpyext`` mechanism (`#527\n`_), and to improve efficiency\n(`rev. 86d825 `_).\n\n1. Declarations of types that provide access via the buffer protocol must\n now include the ``py::buffer_protocol()`` annotation as an argument to\n the ``py::class_`` constructor.\n\n .. code-block:: cpp\n\n py::class_(\"Matrix\", py::buffer_protocol())\n .def(py::init<...>())\n .def_buffer(...);\n\n2. Classes which include static properties (e.g. ``def_readwrite_static()``)\n must now include the ``py::metaclass()`` attribute. Note: this requirement\n has since been removed in v2.1. If you're upgrading from 1.x, it's\n recommended to skip directly to v2.1 or newer.\n\n3. This version of pybind11 uses a redesigned mechanism for instantiating\n trampoline classes that are used to override virtual methods from within\n Python. This led to the following user-visible syntax change:\n\n .. code-block:: cpp\n\n // old v1.x syntax\n py::class_(\"MyClass\")\n .alias()\n ...\n\n // new v2.x syntax\n py::class_(\"MyClass\")\n ...\n\n Importantly, both the original and the trampoline class are now specified\n as arguments to the ``py::class_`` template, and the ``alias<..>()`` call\n is gone. The new scheme has zero overhead in cases when Python doesn't\n override any functions of the underlying C++ class.\n `rev. 86d825 `_.\n\n The class type must be the first template argument given to ``py::class_``\n while the trampoline can be mixed in arbitrary order with other arguments\n (see the following section).\n\n\nDeprecation of the ``py::base()`` attribute\n----------------------------------------------\n\n``py::base()`` was deprecated in favor of specifying ``T`` as a template\nargument to ``py::class_``. This new syntax also supports multiple inheritance.\nNote that, while the type being exported must be the first argument in the\n``py::class_`` template, the order of the following types (bases,\nholder and/or trampoline) is not important.\n\n.. code-block:: cpp\n\n // old v1.x\n py::class_(\"Derived\", py::base());\n\n // new v2.x\n py::class_(\"Derived\");\n\n // new -- multiple inheritance\n py::class_(\"Derived\");\n\n // new -- apart from `Derived` the argument order can be arbitrary\n py::class_(\"Derived\");\n\n\nOut-of-the-box support for ``std::shared_ptr``\n----------------------------------------------\n\nThe relevant type caster is now built in, so it's no longer necessary to\ninclude a declaration of the form:\n\n.. code-block:: cpp\n\n PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr)\n\nContinuing to do so won't cause an error or even a deprecation warning,\nbut it's completely redundant.\n\n\nDeprecation of a few ``py::object`` APIs\n----------------------------------------\n\nAll of the old-style calls emit deprecation warnings.\n\n+---------------------------------------+---------------------------------------------+\n| Old syntax | New syntax |\n+=======================================+=============================================+\n| ``obj.call(args...)`` | ``obj(args...)`` |\n+---------------------------------------+---------------------------------------------+\n| ``obj.str()`` | ``py::str(obj)`` |\n+---------------------------------------+---------------------------------------------+\n| ``auto l = py::list(obj); l.check()`` | ``py::isinstance(obj)`` |\n+---------------------------------------+---------------------------------------------+\n| ``py::object(ptr, true)`` | ``py::reinterpret_borrow(ptr)`` |\n+---------------------------------------+---------------------------------------------+\n| ``py::object(ptr, false)`` | ``py::reinterpret_steal(ptr)`` |\n+---------------------------------------+---------------------------------------------+\n| ``if (obj.attr(\"foo\"))`` | ``if (py::hasattr(obj, \"foo\"))`` |\n+---------------------------------------+---------------------------------------------+\n| ``if (obj[\"bar\"])`` | ``if (obj.contains(\"bar\"))`` |\n+---------------------------------------+---------------------------------------------+\n" }, { "path": "include/pybind11/attr.h", "content": "/*\n pybind11/attr.h: Infrastructure for processing custom\n type and function attributes\n\n Copyright (c) 2016 Wenzel Jakob \n\n All rights reserved. Use of this source code is governed by a\n BSD-style license that can be found in the LICENSE file.\n*/\n\n#pragma once\n\n#include \"detail/common.h\"\n#include \"cast.h\"\n#include \"trampoline_self_life_support.h\"\n\n#include \n\nPYBIND11_NAMESPACE_BEGIN(PYBIND11_NAMESPACE)\n\n/// \\addtogroup annotations\n/// @{\n\n/// Annotation for methods\nstruct is_method {\n handle class_;\n explicit is_method(const handle &c) : class_(c) {}\n};\n\n/// Annotation for setters\nstruct is_setter {};\n\n/// Annotation for operators\nstruct is_operator {};\n\n/// Annotation for classes that cannot be subclassed\nstruct is_final {};\n\n/// Annotation for parent scope\nstruct scope {\n handle value;\n explicit scope(const handle &s) : value(s) {}\n};\n\n/// Annotation for documentation\nstruct doc {\n const char *value;\n explicit doc(const char *value) : value(value) {}\n};\n\n/// Annotation for function names\nstruct name {\n const char *value;\n explicit name(const char *value) : value(value) {}\n};\n\n/// Annotation indicating that a function is an overload associated with a given \"sibling\"\nstruct sibling {\n handle value;\n explicit sibling(const handle &value) : value(value.ptr()) {}\n};\n\n/// Annotation indicating that a class derives from another given type\ntemplate \nstruct base {\n\n PYBIND11_DEPRECATED(\n \"base() was deprecated in favor of specifying 'T' as a template argument to class_\")\n base() = default;\n};\n\n/// Keep patient alive while nurse lives\ntemplate \nstruct keep_alive {};\n\n/// Annotation indicating that a class is involved in a multiple inheritance relationship\nstruct multiple_inheritance {};\n\n/// Annotation which enables dynamic attributes, i.e. adds `__dict__` to a class\nstruct dynamic_attr {};\n\n/// Annotation which enables the buffer protocol for a type\nstruct buffer_protocol {};\n\n/// Annotation which enables releasing the GIL before calling the C++ destructor of wrapped\n/// instances (pybind/pybind11#1446).\nstruct release_gil_before_calling_cpp_dtor {};\n\n/// Annotation which requests that a special metaclass is created for a type\nstruct metaclass {\n handle value;\n\n PYBIND11_DEPRECATED(\"py::metaclass() is no longer required. It's turned on by default now.\")\n metaclass() = default;\n\n /// Override pybind11's default metaclass\n explicit metaclass(handle value) : value(value) {}\n};\n\n/// Specifies a custom callback with signature `void (PyHeapTypeObject*)` that\n/// may be used to customize the Python type.\n///\n/// The callback is invoked immediately before `PyType_Ready`.\n///\n/// Note: This is an advanced interface, and uses of it may require changes to\n/// work with later versions of pybind11. You may wish to consult the\n/// implementation of `make_new_python_type` in `detail/classes.h` to understand\n/// the context in which the callback will be run.\nstruct custom_type_setup {\n using callback = std::function;\n\n explicit custom_type_setup(callback value) : value(std::move(value)) {}\n\n callback value;\n};\n\n/// Annotation that marks a class as local to the module:\nstruct module_local {\n const bool value;\n constexpr explicit module_local(bool v = true) : value(v) {}\n};\n\n/// Annotation to mark enums as an arithmetic type\nstruct arithmetic {};\n\n/// Mark a function for addition at the beginning of the existing overload chain instead of the end\nstruct prepend {};\n\n/** \\rst\n A call policy which places one or more guard variables (``Ts...``) around the function call.\n\n For example, this definition:\n\n .. code-block:: cpp\n\n m.def(\"foo\", foo, py::call_guard());\n\n is equivalent to the following pseudocode:\n\n .. code-block:: cpp\n\n m.def(\"foo\", [](args...) {\n T scope_guard;\n return foo(args...); // forwarded arguments\n });\n \\endrst */\ntemplate \nstruct call_guard;\n\ntemplate <>\nstruct call_guard<> {\n using type = detail::void_type;\n};\n\ntemplate \nstruct call_guard {\n static_assert(std::is_default_constructible::value,\n \"The guard type must be default constructible\");\n\n using type = T;\n};\n\ntemplate \nstruct call_guard {\n struct type {\n T guard{}; // Compose multiple guard types with left-to-right default-constructor order\n typename call_guard::type next{};\n };\n};\n\n/// @} annotations\n\nPYBIND11_NAMESPACE_BEGIN(detail)\n/* Forward declarations */\nenum op_id : int;\nenum op_type : int;\nstruct undefined_t;\ntemplate \nstruct op_;\nvoid keep_alive_impl(size_t Nurse, size_t Patient, function_call &call, handle ret);\n\n/// Internal data structure which holds metadata about a keyword argument\nstruct argument_record {\n const char *name; ///< Argument name\n const char *descr; ///< Human-readable version of the argument value\n handle value; ///< Associated Python object\n bool convert : 1; ///< True if the argument is allowed to convert when loading\n bool none : 1; ///< True if None is allowed when loading\n\n argument_record(const char *name, const char *descr, handle value, bool convert, bool none)\n : name(name), descr(descr), value(value), convert(convert), none(none) {}\n};\n\n/// Internal data structure which holds metadata about a bound function (signature, overloads,\n/// etc.)\n#define PYBIND11_DETAIL_FUNCTION_RECORD_ABI_ID \"v1\" // PLEASE UPDATE if the struct is changed.\nstruct function_record {\n function_record()\n : is_constructor(false), is_new_style_constructor(false), is_stateless(false),\n is_operator(false), is_method(false), is_setter(false), has_args(false),\n has_kwargs(false), prepend(false) {}\n\n /// Function name\n char *name = nullptr; /* why no C++ strings? They generate heavier code.. */\n\n // User-specified documentation string\n char *doc = nullptr;\n\n /// Human-readable version of the function signature\n char *signature = nullptr;\n\n /// List of registered keyword arguments\n std::vector args;\n\n /// Pointer to lambda function which converts arguments and performs the actual call\n handle (*impl)(function_call &) = nullptr;\n\n /// Storage for the wrapped function pointer and captured data, if any\n void *data[3] = {};\n\n /// Pointer to custom destructor for 'data' (if needed)\n void (*free_data)(function_record *ptr) = nullptr;\n\n /// Return value policy associated with this function\n return_value_policy policy = return_value_policy::automatic;\n\n /// True if name == '__init__'\n bool is_constructor : 1;\n\n /// True if this is a new-style `__init__` defined in `detail/init.h`\n bool is_new_style_constructor : 1;\n\n /// True if this is a stateless function pointer\n bool is_stateless : 1;\n\n /// True if this is an operator (__add__), etc.\n bool is_operator : 1;\n\n /// True if this is a method\n bool is_method : 1;\n\n /// True if this is a setter\n bool is_setter : 1;\n\n /// True if the function has a '*args' argument\n bool has_args : 1;\n\n /// True if the function has a '**kwargs' argument\n bool has_kwargs : 1;\n\n /// True if this function is to be inserted at the beginning of the overload resolution chain\n bool prepend : 1;\n\n /// Number of arguments (including py::args and/or py::kwargs, if present)\n std::uint16_t nargs;\n\n /// Number of leading positional arguments, which are terminated by a py::args or py::kwargs\n /// argument or by a py::kw_only annotation.\n std::uint16_t nargs_pos = 0;\n\n /// Number of leading arguments (counted in `nargs`) that are positional-only\n std::uint16_t nargs_pos_only = 0;\n\n /// Python method object\n PyMethodDef *def = nullptr;\n\n /// Python handle to the parent scope (a class or a module)\n handle scope;\n\n /// Python handle to the sibling function representing an overload chain\n handle sibling;\n\n /// Pointer to next overload\n function_record *next = nullptr;\n};\n// The main purpose of this macro is to make it easy to pin-point the critically related code\n// sections.\n#define PYBIND11_ENSURE_PRECONDITION_FOR_FUNCTIONAL_H_PERFORMANCE_OPTIMIZATIONS(...) \\\n static_assert( \\\n __VA_ARGS__, \\\n \"Violation of precondition for pybind11/functional.h performance optimizations!\")\n\n/// Special data structure which (temporarily) holds metadata about a bound class\nstruct type_record {\n PYBIND11_NOINLINE type_record()\n : multiple_inheritance(false), dynamic_attr(false), buffer_protocol(false),\n module_local(false), is_final(false), release_gil_before_calling_cpp_dtor(false) {}\n\n /// Handle to the parent scope\n handle scope;\n\n /// Name of the class\n const char *name = nullptr;\n\n // Pointer to RTTI type_info data structure\n const std::type_info *type = nullptr;\n\n /// How large is the underlying C++ type?\n size_t type_size = 0;\n\n /// What is the alignment of the underlying C++ type?\n size_t type_align = 0;\n\n /// How large is the type's holder?\n size_t holder_size = 0;\n\n /// The global operator new can be overridden with a class-specific variant\n void *(*operator_new)(size_t) = nullptr;\n\n /// Function pointer to class_<..>::init_instance\n void (*init_instance)(instance *, const void *) = nullptr;\n\n /// Function pointer to class_<..>::dealloc\n void (*dealloc)(detail::value_and_holder &) = nullptr;\n\n /// Function pointer for casting alias class (aka trampoline) pointer to\n /// trampoline_self_life_support pointer. Sidesteps cross-DSO RTTI issues\n /// on platforms like macOS (see PR #5728 for details).\n get_trampoline_self_life_support_fn get_trampoline_self_life_support\n = [](void *) -> trampoline_self_life_support * { return nullptr; };\n\n /// List of base classes of the newly created type\n list bases;\n\n /// Optional docstring\n const char *doc = nullptr;\n\n /// Custom metaclass (optional)\n handle metaclass;\n\n /// Custom type setup.\n custom_type_setup::callback custom_type_setup_callback;\n\n /// Multiple inheritance marker\n bool multiple_inheritance : 1;\n\n /// Does the class manage a __dict__?\n bool dynamic_attr : 1;\n\n /// Does the class implement the buffer protocol?\n bool buffer_protocol : 1;\n\n /// Is the class definition local to the module shared object?\n bool module_local : 1;\n\n /// Is the class inheritable from python classes?\n bool is_final : 1;\n\n /// Solves pybind/pybind11#1446\n bool release_gil_before_calling_cpp_dtor : 1;\n\n holder_enum_t holder_enum_v = holder_enum_t::undefined;\n\n PYBIND11_NOINLINE void add_base(const std::type_info &base, void *(*caster)(void *) ) {\n auto *base_info = detail::get_type_info(base, false);\n if (!base_info) {\n std::string tname(base.name());\n detail::clean_type_id(tname);\n pybind11_fail(\"generic_type: type \\\"\" + std::string(name)\n + \"\\\" referenced unknown base type \\\"\" + tname + \"\\\"\");\n }\n\n // SMART_HOLDER_BAKEIN_FOLLOW_ON: Refine holder compatibility checks.\n bool this_has_unique_ptr_holder = (holder_enum_v == holder_enum_t::std_unique_ptr);\n bool base_has_unique_ptr_holder\n = (base_info->holder_enum_v == holder_enum_t::std_unique_ptr);\n if (this_has_unique_ptr_holder != base_has_unique_ptr_holder) {\n std::string tname(base.name());\n detail::clean_type_id(tname);\n pybind11_fail(\"generic_type: type \\\"\" + std::string(name) + \"\\\" \"\n + (this_has_unique_ptr_holder ? \"does not have\" : \"has\")\n + \" a non-default holder type while its base \\\"\" + tname + \"\\\" \"\n + (base_has_unique_ptr_holder ? \"does not\" : \"does\"));\n }\n\n bases.append(reinterpret_cast(base_info->type));\n\n#ifdef PYBIND11_BACKWARD_COMPATIBILITY_TP_DICTOFFSET\n dynamic_attr |= base_info->type->tp_dictoffset != 0;\n#else\n dynamic_attr |= (base_info->type->tp_flags & Py_TPFLAGS_MANAGED_DICT) != 0;\n#endif\n\n if (caster) {\n base_info->implicit_casts.emplace_back(type, caster);\n }\n }\n};\n\ninline function_call::function_call(const function_record &f, handle p) : func(f), parent(p) {\n args.reserve(f.nargs);\n args_convert.reserve(f.nargs);\n}\n\n/// Tag for a new-style `__init__` defined in `detail/init.h`\nstruct is_new_style_constructor {};\n\n/**\n * Partial template specializations to process custom attributes provided to\n * cpp_function_ and class_. These are either used to initialize the respective\n * fields in the type_record and function_record data structures or executed at\n * runtime to deal with custom call policies (e.g. keep_alive).\n */\ntemplate \nstruct process_attribute;\n\ntemplate \nstruct process_attribute_default {\n /// Default implementation: do nothing\n static void init(const T &, function_record *) {}\n static void init(const T &, type_record *) {}\n static void precall(function_call &) {}\n static void postcall(function_call &, handle) {}\n};\n\n/// Process an attribute specifying the function's name\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const name &n, function_record *r) { r->name = const_cast(n.value); }\n};\n\n/// Process an attribute specifying the function's docstring\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const doc &n, function_record *r) { r->doc = const_cast(n.value); }\n};\n\n/// Process an attribute specifying the function's docstring (provided as a C-style string)\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const char *d, function_record *r) { r->doc = const_cast(d); }\n static void init(const char *d, type_record *r) { r->doc = d; }\n};\ntemplate <>\nstruct process_attribute : process_attribute {};\n\n/// Process an attribute indicating the function's return value policy\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const return_value_policy &p, function_record *r) { r->policy = p; }\n};\n\n/// Process an attribute which indicates that this is an overloaded function associated with a\n/// given sibling\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const sibling &s, function_record *r) { r->sibling = s.value; }\n};\n\n/// Process an attribute which indicates that this function is a method\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const is_method &s, function_record *r) {\n r->is_method = true;\n r->scope = s.class_;\n }\n};\n\n/// Process an attribute which indicates that this function is a setter\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const is_setter &, function_record *r) { r->is_setter = true; }\n};\n\n/// Process an attribute which indicates the parent scope of a method\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const scope &s, function_record *r) { r->scope = s.value; }\n};\n\n/// Process an attribute which indicates that this function is an operator\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const is_operator &, function_record *r) { r->is_operator = true; }\n};\n\ntemplate <>\nstruct process_attribute\n : process_attribute_default {\n static void init(const is_new_style_constructor &, function_record *r) {\n r->is_new_style_constructor = true;\n }\n};\n\ninline void check_kw_only_arg(const arg &a, function_record *r) {\n if (r->args.size() > r->nargs_pos && (!a.name || a.name[0] == '\\0')) {\n pybind11_fail(\"arg(): cannot specify an unnamed argument after a kw_only() annotation or \"\n \"args() argument\");\n }\n}\n\ninline void append_self_arg_if_needed(function_record *r) {\n if (r->is_method && r->args.empty()) {\n r->args.emplace_back(\"self\", nullptr, handle(), /*convert=*/true, /*none=*/false);\n }\n}\n\n/// Process a keyword argument attribute (*without* a default value)\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const arg &a, function_record *r) {\n append_self_arg_if_needed(r);\n r->args.emplace_back(a.name, nullptr, handle(), !a.flag_noconvert, a.flag_none);\n\n check_kw_only_arg(a, r);\n }\n};\n\n/// Process a keyword argument attribute (*with* a default value)\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const arg_v &a, function_record *r) {\n if (r->is_method && r->args.empty()) {\n r->args.emplace_back(\n \"self\", /*descr=*/nullptr, /*parent=*/handle(), /*convert=*/true, /*none=*/false);\n }\n\n if (!a.value) {\n#if defined(PYBIND11_DETAILED_ERROR_MESSAGES)\n std::string descr(\"'\");\n if (a.name) {\n descr += std::string(a.name) + \": \";\n }\n descr += a.type + \"'\";\n if (r->is_method) {\n if (r->name) {\n descr += \" in method '\" + (std::string) str(r->scope) + \".\"\n + (std::string) r->name + \"'\";\n } else {\n descr += \" in method of '\" + (std::string) str(r->scope) + \"'\";\n }\n } else if (r->name) {\n descr += \" in function '\" + (std::string) r->name + \"'\";\n }\n pybind11_fail(\"arg(): could not convert default argument \" + descr\n + \" into a Python object (type not registered yet?)\");\n#else\n pybind11_fail(\"arg(): could not convert default argument \"\n \"into a Python object (type not registered yet?). \"\n \"#define PYBIND11_DETAILED_ERROR_MESSAGES or compile in debug mode for \"\n \"more information.\");\n#endif\n }\n r->args.emplace_back(a.name, a.descr, a.value.inc_ref(), !a.flag_noconvert, a.flag_none);\n\n check_kw_only_arg(a, r);\n }\n};\n\n/// Process a keyword-only-arguments-follow pseudo argument\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const kw_only &, function_record *r) {\n append_self_arg_if_needed(r);\n if (r->has_args && r->nargs_pos != static_cast(r->args.size())) {\n pybind11_fail(\"Mismatched args() and kw_only(): they must occur at the same relative \"\n \"argument location (or omit kw_only() entirely)\");\n }\n r->nargs_pos = static_cast(r->args.size());\n }\n};\n\n/// Process a positional-only-argument maker\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const pos_only &, function_record *r) {\n append_self_arg_if_needed(r);\n r->nargs_pos_only = static_cast(r->args.size());\n if (r->nargs_pos_only > r->nargs_pos) {\n pybind11_fail(\"pos_only(): cannot follow a py::args() argument\");\n }\n // It also can't follow a kw_only, but a static_assert in pybind11.h checks that\n }\n};\n\n/// Process a parent class attribute. Single inheritance only (class_ itself already guarantees\n/// that)\ntemplate \nstruct process_attribute::value>>\n : process_attribute_default {\n static void init(const handle &h, type_record *r) { r->bases.append(h); }\n};\n\n/// Process a parent class attribute (deprecated, does not support multiple inheritance)\ntemplate \nstruct process_attribute> : process_attribute_default> {\n static void init(const base &, type_record *r) { r->add_base(typeid(T), nullptr); }\n};\n\n/// Process a multiple inheritance attribute\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const multiple_inheritance &, type_record *r) {\n r->multiple_inheritance = true;\n }\n};\n\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const dynamic_attr &, type_record *r) { r->dynamic_attr = true; }\n};\n\ntemplate <>\nstruct process_attribute {\n static void init(const custom_type_setup &value, type_record *r) {\n r->custom_type_setup_callback = value.value;\n }\n};\n\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const is_final &, type_record *r) { r->is_final = true; }\n};\n\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const buffer_protocol &, type_record *r) { r->buffer_protocol = true; }\n};\n\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const metaclass &m, type_record *r) { r->metaclass = m.value; }\n};\n\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const module_local &l, type_record *r) { r->module_local = l.value; }\n};\n\ntemplate <>\nstruct process_attribute\n : process_attribute_default {\n static void init(const release_gil_before_calling_cpp_dtor &, type_record *r) {\n r->release_gil_before_calling_cpp_dtor = true;\n }\n};\n\n/// Process a 'prepend' attribute, putting this at the beginning of the overload chain\ntemplate <>\nstruct process_attribute : process_attribute_default {\n static void init(const prepend &, function_record *r) { r->prepend = true; }\n};\n\n/// Process an 'arithmetic' attribute for enums (does nothing here)\ntemplate <>\nstruct process_attribute : process_attribute_default {};\n\ntemplate \nstruct process_attribute> : process_attribute_default> {};\n\n/**\n * Process a keep_alive call policy -- invokes keep_alive_impl during the\n * pre-call handler if both Nurse, Patient != 0 and use the post-call handler\n * otherwise\n */\ntemplate \nstruct process_attribute>\n : public process_attribute_default> {\n template = 0>\n static void precall(function_call &call) {\n keep_alive_impl(Nurse, Patient, call, handle());\n }\n template = 0>\n static void postcall(function_call &, handle) {}\n template = 0>\n static void precall(function_call &) {}\n template = 0>\n static void postcall(function_call &call, handle ret) {\n keep_alive_impl(Nurse, Patient, call, ret);\n }\n};\n\n/// Recursively iterate over variadic template arguments\ntemplate \nstruct process_attributes {\n static void init(const Args &...args, function_record *r) {\n PYBIND11_WORKAROUND_INCORRECT_MSVC_C4100(r);\n PYBIND11_WORKAROUND_INCORRECT_GCC_UNUSED_BUT_SET_PARAMETER(r);\n using expander = int[];\n (void) expander{\n 0, ((void) process_attribute::type>::init(args, r), 0)...};\n }\n static void init(const Args &...args, type_record *r) {\n PYBIND11_WORKAROUND_INCORRECT_MSVC_C4100(r);\n PYBIND11_WORKAROUND_INCORRECT_GCC_UNUSED_BUT_SET_PARAMETER(r);\n using expander = int[];\n (void) expander{0,\n (process_attribute::type>::init(args, r), 0)...};\n }\n static void precall(function_call &call) {\n PYBIND11_WORKAROUND_INCORRECT_MSVC_C4100(call);\n using expander = int[];\n (void) expander{0,\n (process_attribute::type>::precall(call), 0)...};\n }\n static void postcall(function_call &call, handle fn_ret) {\n PYBIND11_WORKAROUND_INCORRECT_MSVC_C4100(call, fn_ret);\n PYBIND11_WORKAROUND_INCORRECT_GCC_UNUSED_BUT_SET_PARAMETER(fn_ret);\n using expander = int[];\n (void) expander{\n 0, (process_attribute::type>::postcall(call, fn_ret), 0)...};\n }\n};\n\ntemplate \nstruct is_keep_alive : std::false_type {};\n\ntemplate \nstruct is_keep_alive> : std::true_type {};\n\ntemplate \nusing is_call_guard = is_instantiation;\n\n/// Extract the ``type`` from the first `call_guard` in `Extras...` (or `void_type` if none found)\ntemplate \nusing extract_guard_t = typename exactly_one_t, Extra...>::type;\n\n/// Check the number of named arguments at compile time\ntemplate ::value...),\n size_t self = constexpr_sum(std::is_same::value...)>\nconstexpr bool expected_num_args(size_t nargs, bool has_args, bool has_kwargs) {\n PYBIND11_WORKAROUND_INCORRECT_MSVC_C4100(nargs, has_args, has_kwargs);\n return named == 0\n || (self + named + static_cast(has_args) + static_cast(has_kwargs))\n == nargs;\n}\n\nPYBIND11_NAMESPACE_END(detail)\nPYBIND11_NAMESPACE_END(PYBIND11_NAMESPACE)\n" }, { "path": "include/pybind11/buffer_info.h", "content": "/*\n pybind11/buffer_info.h: Python buffer object interface\n\n Copyright (c) 2016 Wenzel Jakob \n\n All rights reserved. Use of this source code is governed by a\n BSD-style license that can be found in the LICENSE file.\n*/\n\n#pragma once\n\n#include \"detail/common.h\"\n\nPYBIND11_NAMESPACE_BEGIN(PYBIND11_NAMESPACE)\n\nPYBIND11_NAMESPACE_BEGIN(detail)\n\n// Default, C-style strides\ninline std::vector c_strides(const std::vector &shape, ssize_t itemsize) {\n auto ndim = shape.size();\n std::vector strides(ndim, itemsize);\n if (ndim > 0) {\n for (size_t i = ndim - 1; i > 0; --i) {\n strides[i - 1] = strides[i] * shape[i];\n }\n }\n return strides;\n}\n\n// F-style strides; default when constructing an array_t with `ExtraFlags & f_style`\ninline std::vector f_strides(const std::vector &shape, ssize_t itemsize) {\n auto ndim = shape.size();\n std::vector strides(ndim, itemsize);\n for (size_t i = 1; i < ndim; ++i) {\n strides[i] = strides[i - 1] * shape[i - 1];\n }\n return strides;\n}\n\ntemplate \nstruct compare_buffer_info;\n\nPYBIND11_NAMESPACE_END(detail)\n\n/// Information record describing a Python buffer object\nstruct buffer_info {\n void *ptr = nullptr; // Pointer to the underlying storage\n ssize_t itemsize = 0; // Size of individual items in bytes\n ssize_t size = 0; // Total number of entries\n std::string format; // For homogeneous buffers, this should be set to\n // format_descriptor::format()\n ssize_t ndim = 0; // Number of dimensions\n std::vector shape; // Shape of the tensor (1 entry per dimension)\n std::vector strides; // Number of bytes between adjacent entries\n // (for each per dimension)\n bool readonly = false; // flag to indicate if the underlying storage may be written to\n\n buffer_info() = default;\n\n buffer_info(void *ptr,\n ssize_t itemsize,\n const std::string &format,\n ssize_t ndim,\n detail::any_container shape_in,\n detail::any_container strides_in,\n bool readonly = false)\n : ptr(ptr), itemsize(itemsize), size(1), format(format), ndim(ndim),\n shape(std::move(shape_in)), strides(std::move(strides_in)), readonly(readonly) {\n if (ndim != static_cast(shape.size())\n || ndim != static_cast(strides.size())) {\n pybind11_fail(\"buffer_info: ndim doesn't match shape and/or strides length\");\n }\n for (size_t i = 0; i < static_cast(ndim); ++i) {\n size *= shape[i];\n }\n }\n\n template \n buffer_info(T *ptr,\n detail::any_container shape_in,\n detail::any_container strides_in,\n bool readonly = false)\n : buffer_info(private_ctr_tag(),\n ptr,\n sizeof(T),\n format_descriptor::format(),\n static_cast(shape_in->size()),\n std::move(shape_in),\n std::move(strides_in),\n readonly) {}\n\n buffer_info(void *ptr,\n ssize_t itemsize,\n const std::string &format,\n ssize_t size,\n bool readonly = false)\n : buffer_info(ptr, itemsize, format, 1, {size}, {itemsize}, readonly) {}\n\n template \n buffer_info(T *ptr, ssize_t size, bool readonly = false)\n : buffer_info(ptr, sizeof(T), format_descriptor::format(), size, readonly) {}\n\n template \n buffer_info(const T *ptr, ssize_t size, bool readonly = true)\n : buffer_info(\n const_cast(ptr), sizeof(T), format_descriptor::format(), size, readonly) {}\n\n explicit buffer_info(Py_buffer *view, bool ownview = true)\n : buffer_info(\n view->buf,\n view->itemsize,\n view->format,\n view->ndim,\n {view->shape, view->shape + view->ndim},\n /* Though buffer::request() requests PyBUF_STRIDES, ctypes objects\n * ignore this flag and return a view with NULL strides.\n * When strides are NULL, build them manually. */\n view->strides\n ? std::vector(view->strides, view->strides + view->ndim)\n : detail::c_strides({view->shape, view->shape + view->ndim}, view->itemsize),\n (view->readonly != 0)) {\n // NOLINTNEXTLINE(cppcoreguidelines-prefer-member-initializer)\n this->m_view = view;\n // NOLINTNEXTLINE(cppcoreguidelines-prefer-member-initializer)\n this->ownview = ownview;\n }\n\n buffer_info(const buffer_info &) = delete;\n buffer_info &operator=(const buffer_info &) = delete;\n\n buffer_info(buffer_info &&other) noexcept { (*this) = std::move(other); }\n\n buffer_info &operator=(buffer_info &&rhs) noexcept {\n ptr = rhs.ptr;\n itemsize = rhs.itemsize;\n size = rhs.size;\n format = std::move(rhs.format);\n ndim = rhs.ndim;\n shape = std::move(rhs.shape);\n strides = std::move(rhs.strides);\n std::swap(m_view, rhs.m_view);\n std::swap(ownview, rhs.ownview);\n readonly = rhs.readonly;\n return *this;\n }\n\n ~buffer_info() {\n if (m_view && ownview) {\n PyBuffer_Release(m_view);\n delete m_view;\n }\n }\n\n Py_buffer *view() const { return m_view; }\n Py_buffer *&view() { return m_view; }\n\n /* True if the buffer item type is equivalent to `T`. */\n // To define \"equivalent\" by example:\n // `buffer_info::item_type_is_equivalent_to(b)` and\n // `buffer_info::item_type_is_equivalent_to(b)` may both be true\n // on some platforms, but `int` and `unsigned` will never be equivalent.\n // For the ground truth, please inspect `detail::compare_buffer_info<>`.\n template \n bool item_type_is_equivalent_to() const {\n return detail::compare_buffer_info::compare(*this);\n }\n\nprivate:\n struct private_ctr_tag {};\n\n buffer_info(private_ctr_tag,\n void *ptr,\n ssize_t itemsize,\n const std::string &format,\n ssize_t ndim,\n detail::any_container &&shape_in,\n detail::any_container &&strides_in,\n bool readonly)\n : buffer_info(\n ptr, itemsize, format, ndim, std::move(shape_in), std::move(strides_in), readonly) {}\n\n Py_buffer *m_view = nullptr;\n bool ownview = false;\n};\n\nPYBIND11_NAMESPACE_BEGIN(detail)\n\ntemplate \nstruct compare_buffer_info {\n static bool compare(const buffer_info &b) {\n // NOLINTNEXTLINE(bugprone-sizeof-expression) Needed for `PyObject *`\n return b.format == format_descriptor::format() && b.itemsize == (ssize_t) sizeof(T);\n }\n};\n\ntemplate \nstruct compare_buffer_info::value>> {\n static bool compare(const buffer_info &b) {\n return static_cast(b.itemsize) == sizeof(T)\n && (b.format == format_descriptor::value\n || ((sizeof(T) == sizeof(long))\n && b.format == (std::is_unsigned::value ? \"L\" : \"l\"))\n || ((sizeof(T) == sizeof(size_t))\n && b.format == (std::is_unsigned::value ? \"N\" : \"n\")));\n }\n};\n\nPYBIND11_NAMESPACE_END(detail)\nPYBIND11_NAMESPACE_END(PYBIND11_NAMESPACE)\n" }, { "path": "include/pybind11/cast.h", "content": "/*\n pybind11/cast.h: Partial template specializations to cast between\n C++ and Python types\n\n Copyright (c) 2016 Wenzel Jakob \n\n All rights reserved. Use of this source code is governed by a\n BSD-style license that can be found in the LICENSE file.\n*/\n\n#pragma once\n\n#include \"detail/argument_vector.h\"\n#include \"detail/common.h\"\n#include \"detail/descr.h\"\n#include \"detail/holder_caster_foreign_helpers.h\"\n#include \"detail/native_enum_data.h\"\n#include \"detail/type_caster_base.h\"\n#include \"detail/typeid.h\"\n#include \"pytypes.h\"\n\n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n\nPYBIND11_NAMESPACE_BEGIN(PYBIND11_NAMESPACE)\n\nPYBIND11_WARNING_DISABLE_MSVC(4127)\n\nPYBIND11_NAMESPACE_BEGIN(detail)\n\ntemplate \nclass type_caster : public type_caster_base {};\ntemplate \nusing make_caster = type_caster>;\n\n// Shortcut for calling a caster's `cast_op_type` cast operator for casting a type_caster to a T\ntemplate \ntypename make_caster::template cast_op_type cast_op(make_caster &caster) {\n using result_t = typename make_caster::template cast_op_type; // See PR #4893\n return caster.operator result_t();\n}\ntemplate \ntypename make_caster::template cast_op_type::type>\ncast_op(make_caster &&caster) {\n using result_t = typename make_caster::template cast_op_type<\n typename std::add_rvalue_reference::type>; // See PR #4893\n return std::move(caster).operator result_t();\n}\n\ntemplate \nclass type_caster_enum_type {\nprivate:\n using Underlying = typename std::underlying_type::type;\n\npublic:\n static constexpr auto name = const_name();\n\n template \n static handle cast(SrcType &&src, return_value_policy, handle parent) {\n handle native_enum\n = global_internals_native_enum_type_map_get_item(std::type_index(typeid(EnumType)));\n if (native_enum) {\n return native_enum(static_cast(src)).release();\n }\n return type_caster_base::cast(\n std::forward(src),\n // Fixes https://github.com/pybind/pybind11/pull/3643#issuecomment-1022987818:\n return_value_policy::copy,\n parent);\n }\n\n template \n static handle cast(SrcType *src, return_value_policy policy, handle parent) {\n return cast(*src, policy, parent);\n }\n\n bool load(handle src, bool convert) {\n handle native_enum\n = global_internals_native_enum_type_map_get_item(std::type_index(typeid(EnumType)));\n if (native_enum) {\n if (!isinstance(src, native_enum)) {\n return false;\n }\n type_caster underlying_caster;\n if (!underlying_caster.load(src.attr(\"value\"), convert)) {\n pybind11_fail(\"native_enum internal consistency failure.\");\n }\n native_value = static_cast(static_cast(underlying_caster));\n native_loaded = true;\n return true;\n }\n\n type_caster_base legacy_caster;\n if (legacy_caster.load(src, convert)) {\n legacy_ptr = static_cast(legacy_caster);\n return true;\n }\n return false;\n }\n\n template \n using cast_op_type = detail::cast_op_type;\n\n // NOLINTNEXTLINE(google-explicit-constructor)\n operator EnumType *() { return native_loaded ? &native_value : legacy_ptr; }\n\n // NOLINTNEXTLINE(google-explicit-constructor)\n operator EnumType &() {\n if (!native_loaded && !legacy_ptr) {\n throw reference_cast_error();\n }\n return native_loaded ? native_value : *legacy_ptr;\n }\n\nprivate:\n EnumType native_value; // if loading a py::native_enum\n bool native_loaded = false;\n EnumType *legacy_ptr = nullptr; // if loading a py::enum_\n};\n\ntemplate \nstruct type_caster_enum_type_enabled : std::true_type {};\n\ntemplate \nstruct type_uses_type_caster_enum_type {\n static constexpr bool value\n = std::is_enum::value && type_caster_enum_type_enabled::value;\n};\n\ntemplate \nclass type_caster::value>>\n : public type_caster_enum_type {};\n\ntemplate ::value, int> = 0>\nbool isinstance_native_enum_impl(handle obj, const std::type_info &tp) {\n handle native_enum = global_internals_native_enum_type_map_get_item(tp);\n if (!native_enum) {\n return false;\n }\n return isinstance(obj, native_enum);\n}\n\ntemplate ::value, int> = 0>\nbool isinstance_native_enum_impl(handle, const std::type_info &) {\n return false;\n}\n\ntemplate \nbool isinstance_native_enum(handle obj, const std::type_info &tp) {\n return isinstance_native_enum_impl>(obj, tp);\n}\n\ntemplate \nclass type_caster> {\nprivate:\n using caster_t = make_caster;\n caster_t subcaster;\n using reference_t = type &;\n using subcaster_cast_op_type = typename caster_t::template cast_op_type;\n\n static_assert(\n std::is_same::type &, subcaster_cast_op_type>::value\n || std::is_same::value,\n \"std::reference_wrapper caster requires T to have a caster with an \"\n \"`operator T &()` or `operator const T &()`\");\n\npublic:\n bool load(handle src, bool convert) { return subcaster.load(src, convert); }\n static constexpr auto name = caster_t::name;\n static handle\n cast(const std::reference_wrapper &src, return_value_policy policy, handle parent) {\n // It is definitely wrong to take ownership of this pointer, so mask that rvp\n if (policy == return_value_policy::take_ownership\n || policy == return_value_policy::automatic) {\n policy = return_value_policy::automatic_reference;\n }\n return caster_t::cast(&src.get(), policy, parent);\n }\n template \n using cast_op_type = std::reference_wrapper;\n explicit operator std::reference_wrapper() { return cast_op(subcaster); }\n};\n\n#define PYBIND11_TYPE_CASTER(type, py_name) \\\nprotected: \\\n type value; \\\n \\\npublic: \\\n static constexpr auto name = py_name; \\\n template >::value, \\\n int> \\\n = 0> \\\n static ::pybind11::handle cast( \\\n T_ *src, ::pybind11::return_value_policy policy, ::pybind11::handle parent) { \\\n if (!src) \\\n return ::pybind11::none().release(); \\\n if (policy == ::pybind11::return_value_policy::take_ownership) { \\\n auto h = cast(std::move(*src), policy, parent); \\\n delete src; \\\n return h; \\\n } \\\n return cast(*src, policy, parent); \\\n } \\\n operator type *() { return &value; } /* NOLINT(bugprone-macro-parentheses) */ \\\n operator type &() { return value; } /* NOLINT(bugprone-macro-parentheses) */ \\\n operator type &&() && { return std::move(value); } /* NOLINT(bugprone-macro-parentheses) */ \\\n template \\\n using cast_op_type = ::pybind11::detail::movable_cast_op_type\n\ntemplate \nusing is_std_char_type = any_of, /* std::string */\n#if defined(PYBIND11_HAS_U8STRING)\n std::is_same, /* std::u8string */\n#endif\n std::is_same, /* std::u16string */\n std::is_same, /* std::u32string */\n std::is_same /* std::wstring */\n >;\n\ntemplate \nstruct type_caster::value && !is_std_char_type::value>> {\n using _py_type_0 = conditional_t;\n using _py_type_1 = conditional_t::value,\n _py_type_0,\n typename std::make_unsigned<_py_type_0>::type>;\n using py_type = conditional_t::value, double, _py_type_1>;\n\npublic:\n bool load(handle src, bool convert) {\n py_type py_value;\n\n if (!src) {\n return false;\n }\n\n if (std::is_floating_point::value) {\n if (convert || PyFloat_Check(src.ptr()) || PYBIND11_LONG_CHECK(src.ptr())) {\n py_value = (py_type) PyFloat_AsDouble(src.ptr());\n } else {\n return false;\n }\n } else if (PyFloat_Check(src.ptr())\n || !(convert || PYBIND11_LONG_CHECK(src.ptr())\n || PYBIND11_INDEX_CHECK(src.ptr()))) {\n // Explicitly reject float → int conversion even in convert mode.\n // This prevents silent truncation (e.g., 1.9 → 1).\n // Only int → float conversion is allowed (widening, no precision loss).\n // Also reject if none of the conversion conditions are met.\n return false;\n } else {\n handle src_or_index = src;\n // PyPy: 7.3.7's 3.8 does not implement PyLong_*'s __index__ calls.\n#if defined(PYPY_VERSION)\n object index;\n // If not a PyLong, we need to call PyNumber_Index explicitly on PyPy.\n // When convert is false, we only reach here if PYBIND11_INDEX_CHECK passed above.\n if (!PYBIND11_LONG_CHECK(src.ptr())) {\n index = reinterpret_steal(PyNumber_Index(src.ptr()));\n if (!index) {\n PyErr_Clear();\n if (!convert)\n return false;\n } else {\n src_or_index = index;\n }\n }\n#endif\n if (std::is_unsigned::value) {\n py_value = as_unsigned(src_or_index.ptr());\n } else { // signed integer:\n py_value = sizeof(T) <= sizeof(long)\n ? (py_type) PyLong_AsLong(src_or_index.ptr())\n : (py_type) PYBIND11_LONG_AS_LONGLONG(src_or_index.ptr());\n }\n }\n\n bool py_err = (PyErr_Occurred() != nullptr);\n if (py_err) {\n assert(py_value == static_cast(-1));\n }\n\n // Check to see if the conversion is valid (integers should match exactly)\n // Signed/unsigned checks happen elsewhere\n if (py_err\n || (std::is_integral::value && sizeof(py_type) != sizeof(T)\n && py_value != (py_type) (T) py_value)) {\n PyErr_Clear();\n if (py_err && convert && (PyNumber_Check(src.ptr()) != 0)) {\n auto tmp = reinterpret_steal(std::is_floating_point::value\n ? PyNumber_Float(src.ptr())\n : PyNumber_Long(src.ptr()));\n PyErr_Clear();\n return load(tmp, false);\n }\n return false;\n }\n\n value = (T) py_value;\n return true;\n }\n\n template \n static typename std::enable_if::value, handle>::type\n cast(U src, return_value_policy /* policy */, handle /* parent */) {\n return PyFloat_FromDouble((double) src);\n }\n\n template \n static typename std::enable_if::value && std::is_signed::value\n && (sizeof(U) <= sizeof(long)),\n handle>::type\n cast(U src, return_value_policy /* policy */, handle /* parent */) {\n return PYBIND11_LONG_FROM_SIGNED((long) src);\n }\n\n template \n static typename std::enable_if::value && std::is_unsigned::value\n && (sizeof(U) <= sizeof(unsigned long)),\n handle>::type\n cast(U src, return_value_policy /* policy */, handle /* parent */) {\n return PYBIND11_LONG_FROM_UNSIGNED((unsigned long) src);\n }\n\n template \n static typename std::enable_if::value && std::is_signed::value\n && (sizeof(U) > sizeof(long)),\n handle>::type\n cast(U src, return_value_policy /* policy */, handle /* parent */) {\n return PyLong_FromLongLong((long long) src);\n }\n\n template \n static typename std::enable_if::value && std::is_unsigned::value\n && (sizeof(U) > sizeof(unsigned long)),\n handle>::type\n cast(U src, return_value_policy /* policy */, handle /* parent */) {\n return PyLong_FromUnsignedLongLong((unsigned long long) src);\n }\n\n PYBIND11_TYPE_CASTER(\n T,\n io_name::value>(\"typing.SupportsInt | typing.SupportsIndex\",\n \"int\",\n \"typing.SupportsFloat | typing.SupportsIndex\",\n \"float\"));\n};\n\ntemplate \nstruct void_caster {\npublic:\n bool load(handle src, bool) {\n if (src && src.is_none()) {\n return true;\n }\n return false;\n }\n static handle cast(T, return_value_policy /* policy */, handle /* parent */) {\n return none().release();\n }\n PYBIND11_TYPE_CASTER(T, const_name(\"None\"));\n};\n\ntemplate <>\nclass type_caster : public void_caster {};\n\ntemplate <>\nclass type_caster : public type_caster {\npublic:\n using type_caster::cast;\n\n bool load(handle h, bool) {\n if (!h) {\n return false;\n }\n if (h.is_none()) {\n value = nullptr;\n return true;\n }\n\n /* Check if this is a capsule */\n if (isinstance(h)) {\n value = reinterpret_borrow(h);\n return true;\n }\n\n /* Check if this is a C++ type */\n const auto &bases\n = all_type_info(reinterpret_cast(type::handle_of(h).ptr()));\n if (bases.size() == 1) { // Only allowing loading from a single-value type\n value = values_and_holders(reinterpret_cast(h.ptr())).begin()->value_ptr();\n return true;\n }\n\n /* Fail */\n return false;\n }\n\n static handle cast(const void *ptr, return_value_policy /* policy */, handle /* parent */) {\n if (ptr) {\n return capsule(ptr).release();\n }\n return none().release();\n }\n\n template \n using cast_op_type = void *&;\n explicit operator void *&() { return value; }\n static constexpr auto name = const_name(PYBIND11_CAPSULE_TYPE_TYPE_HINT);\n\nprivate:\n void *value = nullptr;\n};\n\ntemplate <>\nclass type_caster : public void_caster {};\n\ntemplate <>\nclass type_caster {\npublic:\n bool load(handle src, bool convert) {\n if (!src) {\n return false;\n }\n if (src.ptr() == Py_True) {\n value = true;\n return true;\n }\n if (src.ptr() == Py_False) {\n value = false;\n return true;\n }\n if (convert || is_numpy_bool(src)) {\n // (allow non-implicit conversion for numpy booleans), use strncmp\n // since NumPy 1.x had an additional trailing underscore.\n\n Py_ssize_t res = -1;\n if (src.is_none()) {\n res = 0; // None is implicitly converted to False\n }\n#if defined(PYPY_VERSION)\n // On PyPy, check that \"__bool__\" attr exists\n else if (hasattr(src, PYBIND11_BOOL_ATTR)) {\n res = PyObject_IsTrue(src.ptr());\n }\n#else\n // Alternate approach for CPython: this does the same as the above, but optimized\n // using the CPython API so as to avoid an unneeded attribute lookup.\n else if (auto *tp_as_number = Py_TYPE(src.ptr())->tp_as_number) {\n if (PYBIND11_NB_BOOL(tp_as_number)) {\n res = (*PYBIND11_NB_BOOL(tp_as_number))(src.ptr());\n }\n }\n#endif\n if (res == 0 || res == 1) {\n value = (res != 0);\n return true;\n }\n PyErr_Clear();\n }\n return false;\n }\n static handle cast(bool src, return_value_policy /* policy */, handle /* parent */) {\n return handle(src ? Py_True : Py_False).inc_ref();\n }\n PYBIND11_TYPE_CASTER(bool, const_name(\"bool\"));\n\nprivate:\n // Test if an object is a NumPy boolean (without fetching the type).\n static bool is_numpy_bool(handle object) {\n const char *type_name = Py_TYPE(object.ptr())->tp_name;\n // Name changed to `numpy.bool` in NumPy 2, `numpy.bool_` is needed for 1.x support\n return std::strcmp(\"numpy.bool\", type_name) == 0\n || std::strcmp(\"numpy.bool_\", type_name) == 0;\n }\n};\n\n// Helper class for UTF-{8,16,32} C++ stl strings:\ntemplate \nstruct string_caster {\n using CharT = typename StringType::value_type;\n\n // Simplify life by being able to assume standard char sizes (the standard only guarantees\n // minimums, but Python requires exact sizes)\n static_assert(!std::is_same::value || sizeof(CharT) == 1,\n \"Unsupported char size != 1\");\n#if defined(PYBIND11_HAS_U8STRING)\n static_assert(!std::is_same::value || sizeof(CharT) == 1,\n \"Unsupported char8_t size != 1\");\n#endif\n static_assert(!std::is_same::value || sizeof(CharT) == 2,\n \"Unsupported char16_t size != 2\");\n static_assert(!std::is_same::value || sizeof(CharT) == 4,\n \"Unsupported char32_t size != 4\");\n // wchar_t can be either 16 bits (Windows) or 32 (everywhere else)\n static_assert(!std::is_same::value || sizeof(CharT) == 2 || sizeof(CharT) == 4,\n \"Unsupported wchar_t size != 2/4\");\n static constexpr size_t UTF_N = 8 * sizeof(CharT);\n\n bool load(handle src, bool) {\n handle load_src = src;\n if (!src) {\n return false;\n }\n if (!PyUnicode_Check(load_src.ptr())) {\n return load_raw(load_src);\n }\n\n // For UTF-8 we avoid the need for a temporary `bytes` object by using\n // `PyUnicode_AsUTF8AndSize`.\n if (UTF_N == 8) {\n Py_ssize_t size = -1;\n const auto *buffer\n = reinterpret_cast(PyUnicode_AsUTF8AndSize(load_src.ptr(), &size));\n if (!buffer) {\n PyErr_Clear();\n return false;\n }\n value = StringType(buffer, static_cast(size));\n return true;\n }\n\n auto utfNbytes\n = reinterpret_steal(PyUnicode_AsEncodedString(load_src.ptr(),\n UTF_N == 8 ? \"utf-8\"\n : UTF_N == 16 ? \"utf-16\"\n : \"utf-32\",\n nullptr));\n if (!utfNbytes) {\n PyErr_Clear();\n return false;\n }\n\n const auto *buffer\n = reinterpret_cast(PYBIND11_BYTES_AS_STRING(utfNbytes.ptr()));\n size_t length = static_cast(PYBIND11_BYTES_SIZE(utfNbytes.ptr())) / sizeof(CharT);\n // Skip BOM for UTF-16/32\n if (UTF_N > 8) {\n buffer++;\n length--;\n }\n value = StringType(buffer, length);\n\n // If we're loading a string_view we need to keep the encoded Python object alive:\n if (IsView) {\n loader_life_support::add_patient(utfNbytes);\n }\n\n return true;\n }\n\n static handle\n cast(const StringType &src, return_value_policy /* policy */, handle /* parent */) {\n const char *buffer = reinterpret_cast(src.data());\n auto nbytes = ssize_t(src.size() * sizeof(CharT));\n handle s = decode_utfN(buffer, nbytes);\n if (!s) {\n throw error_already_set();\n }\n return s;\n }\n\n PYBIND11_TYPE_CASTER(StringType, const_name(PYBIND11_STRING_NAME));\n\nprivate:\n static handle decode_utfN(const char *buffer, ssize_t nbytes) {\n#if !defined(PYPY_VERSION)\n return UTF_N == 8 ? PyUnicode_DecodeUTF8(buffer, nbytes, nullptr)\n : UTF_N == 16 ? PyUnicode_DecodeUTF16(buffer, nbytes, nullptr, nullptr)\n : PyUnicode_DecodeUTF32(buffer, nbytes, nullptr, nullptr);\n#else\n // PyPy segfaults when on PyUnicode_DecodeUTF16 (and possibly on PyUnicode_DecodeUTF32 as\n // well), so bypass the whole thing by just passing the encoding as a string value, which\n // works properly:\n return PyUnicode_Decode(buffer,\n nbytes,\n UTF_N == 8 ? \"utf-8\"\n : UTF_N == 16 ? \"utf-16\"\n : \"utf-32\",\n nullptr);\n#endif\n }\n\n // When loading into a std::string or char*, accept a bytes/bytearray object as-is (i.e.\n // without any encoding/decoding attempt). For other C++ char sizes this is a no-op.\n // which supports loading a unicode from a str, doesn't take this path.\n template \n bool load_raw(enable_if_t::value, handle> src) {\n if (PYBIND11_BYTES_CHECK(src.ptr())) {\n // We were passed raw bytes; accept it into a std::string or char*\n // without any encoding attempt.\n const char *bytes = PYBIND11_BYTES_AS_STRING(src.ptr());\n if (!bytes) {\n pybind11_fail(\"Unexpected PYBIND11_BYTES_AS_STRING() failure.\");\n }\n value = StringType(bytes, (size_t) PYBIND11_BYTES_SIZE(src.ptr()));\n return true;\n }\n if (PyByteArray_Check(src.ptr())) {\n // We were passed a bytearray; accept it into a std::string or char*\n // without any encoding attempt.\n const char *bytearray = PyByteArray_AsString(src.ptr());\n if (!bytearray) {\n pybind11_fail(\"Unexpected PyByteArray_AsString() failure.\");\n }\n value = StringType(bytearray, (size_t) PyByteArray_Size(src.ptr()));\n return true;\n }\n\n return false;\n }\n\n template \n bool load_raw(enable_if_t::value, handle>) {\n return false;\n }\n};\n\ntemplate \nstruct type_caster,\n enable_if_t::value>>\n : string_caster> {};\n\n#ifdef PYBIND11_HAS_STRING_VIEW\ntemplate \nstruct type_caster,\n enable_if_t::value>>\n : string_caster, true> {};\n#endif\n\n// Type caster for C-style strings. We basically use a std::string type caster, but also add the\n// ability to use None as a nullptr char* (which the string caster doesn't allow).\ntemplate \nstruct type_caster::value>> {\n using StringType = std::basic_string;\n using StringCaster = make_caster;\n StringCaster str_caster;\n bool none = false;\n CharT one_char = 0;\n\npublic:\n bool load(handle src, bool convert) {\n if (!src) {\n return false;\n }\n if (src.is_none()) {\n // Defer accepting None to other overloads (if we aren't in convert mode):\n if (!convert) {\n return false;\n }\n none = true;\n return true;\n }\n return str_caster.load(src, convert);\n }\n\n static handle cast(const CharT *src, return_value_policy policy, handle parent) {\n if (src == nullptr) {\n return pybind11::none().release();\n }\n return StringCaster::cast(StringType(src), policy, parent);\n }\n\n static handle cast(CharT src, return_value_policy policy, handle parent) {\n if (std::is_same::value) {\n handle s = PyUnicode_DecodeLatin1((const char *) &src, 1, nullptr);\n if (!s) {\n throw error_already_set();\n }\n return s;\n }\n return StringCaster::cast(StringType(1, src), policy, parent);\n }\n\n explicit operator CharT *() {\n return none ? nullptr : const_cast(static_cast(str_caster).c_str());\n }\n explicit operator CharT &() {\n if (none) {\n throw value_error(\"Cannot convert None to a character\");\n }\n\n auto &value = static_cast(str_caster);\n size_t str_len = value.size();\n if (str_len == 0) {\n throw value_error(\"Cannot convert empty string to a character\");\n }\n\n // If we're in UTF-8 mode, we have two possible failures: one for a unicode character that\n // is too high, and one for multiple unicode characters (caught later), so we need to\n // figure out how long the first encoded character is in bytes to distinguish between these\n // two errors. We also allow want to allow unicode characters U+0080 through U+00FF, as\n // those can fit into a single char value.\n if (StringCaster::UTF_N == 8 && str_len > 1 && str_len <= 4) {\n auto v0 = static_cast(value[0]);\n // low bits only: 0-127\n // 0b110xxxxx - start of 2-byte sequence\n // 0b1110xxxx - start of 3-byte sequence\n // 0b11110xxx - start of 4-byte sequence\n size_t char0_bytes = (v0 & 0x80) == 0 ? 1\n : (v0 & 0xE0) == 0xC0 ? 2\n : (v0 & 0xF0) == 0xE0 ? 3\n : 4;\n\n if (char0_bytes == str_len) {\n // If we have a 128-255 value, we can decode it into a single char:\n if (char0_bytes == 2 && (v0 & 0xFC) == 0xC0) { // 0x110000xx 0x10xxxxxx\n one_char = static_cast(((v0 & 3) << 6)\n + (static_cast(value[1]) & 0x3F));\n return one_char;\n }\n // Otherwise we have a single character, but it's > U+00FF\n throw value_error(\"Character code point not in range(0x100)\");\n }\n }\n\n // UTF-16 is much easier: we can only have a surrogate pair for values above U+FFFF, thus a\n // surrogate pair with total length 2 instantly indicates a range error (but not a \"your\n // string was too long\" error).\n else if (StringCaster::UTF_N == 16 && str_len == 2) {\n one_char = static_cast(value[0]);\n if (one_char >= 0xD800 && one_char < 0xE000) {\n throw value_error(\"Character code point not in range(0x10000)\");\n }\n }\n\n if (str_len != 1) {\n throw value_error(\"Expected a character, but multi-character string found\");\n }\n\n one_char = value[0];\n return one_char;\n }\n\n static constexpr auto name = const_name(PYBIND11_STRING_NAME);\n template \n using cast_op_type = pybind11::detail::cast_op_type<_T>;\n};\n\n// Base implementation for std::tuple and std::pair\ntemplate