* fix: add missing std::forward calls
Two of the four cpp_function overloads are missing std::forward calls, which seems like a simple oversight.
* add test for https://github.com/pybind/pybind11/pull/3443
* add py tests
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* fix test
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Simply has_kw_only_args handling
This simplifies tracking the number of kw-only args by instead tracking
the number of positional arguments (which is really what we care about
everywhere this is used).
* Allow keyword-only arguments to follow py::args
This removes the constraint that py::args has to be last (or
second-last, with py::kwargs) and instead makes py::args imply
py::kw_only for any remaining arguments, allowing you to bind a function
that works the same way as a Python function such as:
def f(a, *args, b):
return a * b + sum(args)
f(10, 1, 2, 3, b=20) # == 206
With this change, you can bind such a function using:
m.def("f", [](int a, py::args args, int b) { /* ... */ },
"a"_a, "b"_a);
Or, to be more explicit about the keyword-only arguments:
m.def("g", [](int a, py::args args, int b) { /* ... */ },
"a"_a, py::kw_only{}, "b"_a);
(The only difference between the two is that the latter will fail at
binding time if the `kw_only{}` doesn't match the `py::args` position).
This doesn't affect backwards compatibility at all because, currently,
you can't have a py::args anywhere except the end/2nd-last.
* Take args/kwargs by const lvalue ref
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* docs: changelog update for 2.8.1
* chore: add one more entry
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* ci: support Python 3.11-dev
Also update 3.10 to final, better PyPy usage
* fix: use PyFrame_GetCode on Python 3.9+
* ci: some bitiness of pypy not supported on win
* chore: update CMake support to 3.22rc1 to quiet warning
* fix: use dev version of py to fix Py 3.11
* tests: print proper Eigen version
* ci: include pypy2, not sure why
* ci: avoid running on Python 3.11 for now
* ci: fix runs
* ci: simpler PyPy usage, drop unmaintained scipy + pypy index
* ci: only binary numpy, wait on pypy 3.8
* refactor: address review
* fix: the types for return_value_policy_override in optional_caster
`return_value_policy_override` was not being applied correctly in
`optional_caster` in two ways:
- The `is_lvalue_reference` condition referenced `T`, which was the
`optional<T>` type parameter from the class, when it should have used `T_`,
which was the parameter to the `cast` function. `T_` can potentially be a
reference type, but `T` will never be.
- The type parameter passed to `return_value_policy_override` should be
`T::value_type`, not `T`. This matches the way that the other STL container
type casters work.
The result of these issues was that a method/property definition which used a
`reference` or `reference_internal` return value policy would create a Python
value that's bound by reference to a temporary C++ object, resulting in
undefined behavior. For reasons that I was not able to figure out fully, it
seems like this causes problems when using old versions of `boost::optional`,
but not with recent versions of `boost::optional` or the `libstdc++`
implementation of `std::optional`. The issue (that the override to
`return_value_policy::move` is never being applied) is present for all
implementations, it just seems like that somehow doesn't result in problems for
the some implementation of `optional`. This change includes a regression type
with a custom optional-like type which was able to reproduce the issue.
Part of the issue with using the wrong types may have stemmed from the type
variables `T` and `T_` having very similar names. This also changes the type
variables in `optional_caster` to use slightly more descriptive names, which
also more closely follow the naming convention used by the other STL casters.
Fixes#3330
* Fix clang-tidy complaints
* Add missing NOLINT
* Apply a couple more fixes
* fix: support GCC 4.8
* tests: avoid warning about unknown compiler for compilers missing C++17
* Remove unneeded test module attribute
* Change test enum to have more unique int values
Co-authored-by: Aaron Gokaslan <skylion.aaron@gmail.com>
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* Adding MSVC C4127 suppression around Eigen includes.
* For MSVC 2015 only: also adding the C4127 suppression to test_eigen.cpp
* Copying original change from PR #3343, with extra line breaks to not run past 99 columns (our desired but currently not enforced limit).
* Add a test showing a flaw in make_key_iterator/make_value_iterator
If the iterator dereference operator returns a value rather than a
reference (and that pair also does not *contain* references),
make_key_iterator and make_value_iterator will return a reference to a
temporary, causing a segfault.
* Fix make_key_iterator/make_value_iterator for prvalue iterators
If an iterator returns a pair<T1, T2> rather than a reference to a pair
or a pair of references, make_key_iterator and make_value_iterator would
return a reference to a temporary, typically leading to a segfault. This
is because the value category of member access to a prvalue is an
xvalue, not a prvalue, so decltype produces an rvalue reference type.
Fix the type calculation to handle this case.
I also removed some decltype parentheses that weren't needed, either
because the expression isn't one of the special cases for decltype or
because decltype was only used for SFINAE. Hopefully that makes the code
a bit more readable.
Closes#3347
* Attempt a workaround for nvcc
* Add `.keys` and `.values` to bind_map
Both of these implement views (rather than just iterators), and `.items`
is also upgraded to a view. In practical terms, this allows a view to be
iterated multiple times and have its size taken, neither of which works
with an iterator.
The views implement `__len__`, `__iter__`, and the keys view implements
`__contains__`. Testing membership also works in item and value views
because Python falls back to iteration. This won't be optimal
for item values since it's linear rather than O(log n) or O(1), but I
didn't fancy trying to get all the corner cases to match Python
behaviour (tuple of wrong types, wrong length tuple, not a tuple etc).
Missing relative to Python dictionary views is `__reversed__` (only
added to Python in 3.8). Implementing that could break code that binds
custom map classes which don't provide `rbegin`/`rend` (at least without
doing clever things with SFINAE), so I've not tried.
The size increase on my system is 131072 bytes, which is rather large
(5%) but also suspiciously round (2^17) and makes me suspect some
quantisation effect.
* bind_map: support any object in __contains__
Add extra overload of `__contains__` (for both the map itself and
KeysView) which takes an arbitrary object and returns false.
* Take py::object by const reference in __contains__
To keep clang-tidy happy.
* Removing stray `py::` (detected via interactive testing in Google environment).
Co-authored-by: Ralf W. Grosse-Kunstleve <rwgk@google.com>
* Docs: Demonstrate non-enum internal types in example
Previously example only demonstrated internal enumeration type.
To show that it works for other internal types the same way the example was updated with an additional struct Pet::Attributes type.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Fix `pybind11::object::operator=` to be safe if `*this` is accessible from Python
* Add `custom_type_setup` attribute
This allows for custom modifications to the PyHeapTypeObject prior to
calling `PyType_Ready`. This may be used, for example, to define
`tp_traverse` and `tp_clear` functions.
The new FindPython-based variant of the CMake scripts caches information
about the chosen Python version that can become stale. For example,
suppose I configure a simple pybind11-based project as follows
```
cmake -S . -B build -GNinja -DPython_ROOT=<path to python 3.8>
```
which will generate `my_extension.cpython-38-x86_64-linux-gnu.so`.
A subsequent change to the python version like
```
cmake -S . -B build -GNinja -DPython_ROOT=<path to python 3.9>
```
does not update all necessary build system information. In particular,
the compiled file is still called
`my_extension.cpython-38-x86_64-linux-gnu.so`.
This commit fixes the problem by detecting changes in
`Python_EXECUTABLE` and re-running Python as needed.
Note that the previous way of detecting Python does not seem to be
affected, it always specifies the right suffix.
