Zengtudor/pybind11
1
0
Fork 0
mirror of https://github.com/pybind/pybind11.git synced 2024-11-30 00:47:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
741576dd11
pybind11/include/pybind11/pybind11.h

2072 lines
90 KiB
C
Raw Normal View History

Initial commit
2015-07-05 18:05:44 +00:00
/*
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
pybind11/pybind11.h: Main header file of the C++11 python
binding generator library
Initial commit
2015-07-05 18:05:44 +00:00
minor cleanups in common.h; updated author info and copyright year
2016-04-17 18:21:41 +00:00
Copyright (c) 2016 Wenzel Jakob <wenzel.jakob@epfl.ch>
Initial commit
2015-07-05 18:05:44 +00:00
All rights reserved. Use of this source code is governed by a
BSD-style license that can be found in the LICENSE file.
*/
more flexible function creation syntax
2015-07-11 15:41:48 +00:00
#pragma once
Initial commit
2015-07-05 18:05:44 +00:00
#if defined(_MSC_VER)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
# pragma warning(push)
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
# pragma warning(disable: 4100) // warning C4100: Unreferenced formal parameter
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
# pragma warning(disable: 4127) // warning C4127: Conditional expression is constant
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
# pragma warning(disable: 4512) // warning C4512: Assignment operator was implicitly defined as deleted
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
# pragma warning(disable: 4800) // warning C4800: 'int': forcing value to bool 'true' or 'false' (performance warning)
# pragma warning(disable: 4996) // warning C4996: The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name
Multiple inheritance support
2016-09-11 11:00:40 +00:00
# pragma warning(disable: 4702) // warning C4702: unreachable code
Later assignments to accessors should not overwrite the original field `auto var = l[0]` has a strange quirk: `var` is actually an accessor and not an object, so any later assignment of `var = ...` would modify l[0] instead of `var`. This is surprising compared to the non-auto assignment `py::object var = l[0]; var = ...`. By overloading `operator=` on lvalue/rvalue, the expected behavior is restored even for `auto` variables.
2016-09-22 22:27:59 +00:00
# pragma warning(disable: 4522) // warning C4522: multiple assignment operators specified
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
#elif defined(__INTEL_COMPILER)
Add intel warning push/pop
2016-02-18 20:25:51 +00:00
# pragma warning(push)
Fix compilation with Intel's compiler ICC was reporting that `try_direct_conversions()` cannot be `constexpr` because `handle` is not a literal type. The fix removes `constexpr` from the function since it isn't strictly needed. This commit also suppresses new false positive warnings which mostly appear in constexpr contexts (where the compiler knows conversions are safe).
2017-07-03 23:27:18 +00:00
# pragma warning(disable: 68) // integer conversion resulted in a change of sign
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
# pragma warning(disable: 186) // pointless comparison of unsigned integer with zero
Fix compilation with Intel's compiler ICC was reporting that `try_direct_conversions()` cannot be `constexpr` because `handle` is not a literal type. The fix removes `constexpr` from the function since it isn't strictly needed. This commit also suppresses new false positive warnings which mostly appear in constexpr contexts (where the compiler knows conversions are safe).
2017-07-03 23:27:18 +00:00
# pragma warning(disable: 878) // incompatible exception specifications
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
# pragma warning(disable: 1334) // the "template" keyword used for syntactic disambiguation may only be used within a template
Fix compilation with Intel's compiler ICC was reporting that `try_direct_conversions()` cannot be `constexpr` because `handle` is not a literal type. The fix removes `constexpr` from the function since it isn't strictly needed. This commit also suppresses new false positive warnings which mostly appear in constexpr contexts (where the compiler knows conversions are safe).
2017-07-03 23:27:18 +00:00
# pragma warning(disable: 1682) // implicit conversion of a 64-bit integral type to a smaller integral type (potential portability problem)
# pragma warning(disable: 1875) // offsetof applied to non-POD (Plain Old Data) types is nonstandard
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
# pragma warning(disable: 2196) // warning #2196: routine is both "inline" and "noinline"
fix incorrect in macro if statement
2016-05-01 18:47:49 +00:00
#elif defined(__GNUG__) && !defined(__clang__)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wunused-but-set-parameter"
# pragma GCC diagnostic ignored "-Wunused-but-set-variable"
# pragma GCC diagnostic ignored "-Wmissing-field-initializers"
quench strict aliasing warnings
2016-05-15 21:54:34 +00:00
# pragma GCC diagnostic ignored "-Wstrict-aliasing"
# pragma GCC diagnostic ignored "-Wattributes"
Only disable -Wnoexcept-type on gcc >= 7
2017-05-09 18:46:15 +00:00
# if __GNUC__ >= 7
# pragma GCC diagnostic ignored "-Wnoexcept-type"
# endif
Initial commit
2015-07-05 18:05:44 +00:00
#endif
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
#include "attr.h"
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
#include "options.h"
Move internal headers into `detail` subdirectory
2017-08-13 22:35:53 +00:00
#include "detail/class.h"
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
#include "detail/init.h"
Initial commit
2015-07-05 18:05:44 +00:00
Force hidden visibility on pybind code This adds a PYBIND11_NAMESPACE macro that expands to the `pybind11` namespace with hidden visibility under gcc-type compilers, and otherwise to the plain `pybind11`. This then forces hidden visibility on everything in pybind, solving the visibility issues discussed at end end of #949.
2017-08-10 16:03:29 +00:00
NAMESPACE_BEGIN(PYBIND11_NAMESPACE)
Initial commit
2015-07-05 18:05:44 +00:00
generate more compact binaries
2015-07-26 14:33:49 +00:00
/// Wraps an arbitrary C++ function/method/lambda function/.. into a callable Python object
more flexible function creation syntax
2015-07-11 15:41:48 +00:00
class cpp_function : public function {
generate more compact binaries
2015-07-26 14:33:49 +00:00
public:
more flexible function creation syntax
2015-07-11 15:41:48 +00:00
cpp_function() { }
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
cpp_function(std::nullptr_t) { }
generate more compact binaries
2015-07-26 14:33:49 +00:00
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/// Construct a cpp_function from a vanilla function pointer
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
template <typename Return, typename... Args, typename... Extra>
cpp_function(Return (*f)(Args...), const Extra&... extra) {
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
initialize(f, f, extra...);
generate more compact binaries
2015-07-26 14:33:49 +00:00
}
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/// Construct a cpp_function from a lambda function (possibly with internal state)
Added metatypes for dealing with functions/lambdas `function_signature_t` extracts the function type from a function, function pointer, or lambda. `is_lambda` (which is really `is_not_a_function_or_pointer_or_member_pointer`, but that name is a bit too long) checks whether the type is (in the approprate context) a lambda. `is_function_pointer` checks whether the type is a pointer to a function.
2017-05-10 05:51:08 +00:00
template <typename Func, typename... Extra,
typename = detail::enable_if_t<detail::is_lambda<Func>::value>>
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
cpp_function(Func &&f, const Extra&... extra) {
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
initialize(std::forward<Func>(f),
Added metatypes for dealing with functions/lambdas `function_signature_t` extracts the function type from a function, function pointer, or lambda. `is_lambda` (which is really `is_not_a_function_or_pointer_or_member_pointer`, but that name is a bit too long) checks whether the type is (in the approprate context) a lambda. `is_function_pointer` checks whether the type is a pointer to a function.
2017-05-10 05:51:08 +00:00
(detail::function_signature_t<Func> *) nullptr, extra...);
generate more compact binaries
2015-07-26 14:33:49 +00:00
}
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/// Construct a cpp_function from a class method (non-const)
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
template <typename Return, typename Class, typename... Arg, typename... Extra>
cpp_function(Return (Class::*f)(Arg...), const Extra&... extra) {
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
initialize([f](Class *c, Arg... args) -> Return { return (c->*f)(args...); },
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
(Return (*) (Class *, Arg...)) nullptr, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
}
generate more compact binaries
2015-07-26 14:33:49 +00:00
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/// Construct a cpp_function from a class method (const)
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
template <typename Return, typename Class, typename... Arg, typename... Extra>
cpp_function(Return (Class::*f)(Arg...) const, const Extra&... extra) {
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
initialize([f](const Class *c, Arg... args) -> Return { return (c->*f)(args...); },
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
(Return (*)(const Class *, Arg ...)) nullptr, extra...);
generate more compact binaries
2015-07-26 14:33:49 +00:00
}
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
/// Return the function name
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
object name() const { return attr("__name__"); }
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
protected:
operators should return NotImplemented given unsupported input (fixes #393)
2016-09-10 06:28:37 +00:00
/// Space optimization: don't inline this frequently instantiated fragment
PYBIND11_NOINLINE detail::function_record *make_function_record() {
return new detail::function_record();
}
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/// Special internal constructor for functors, lambda functions, etc.
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
template <typename Func, typename Return, typename... Args, typename... Extra>
void initialize(Func &&f, Return (*)(Args...), const Extra&... extra) {
Use semi-constexpr signatures on MSVC MSCV does not allow `&typeid(T)` in constexpr contexts, but the string part of the type signature can still be constexpr. In order to avoid `typeid` as long as possible, `descr` is modified to collect type information as template parameters instead of constexpr `typeid`. The actual `std::type_info` pointers are only collected in the end, as a `constexpr` (gcc/clang) or regular (MSVC) function call. Not only does it significantly reduce binary size on MSVC, gcc/clang benefit a little bit as well, since they can skip some intermediate `std::type_info*` arrays.
2017-07-02 10:52:00 +00:00
using namespace detail;
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
struct capture { remove_reference_t<Func> f; };
generate more compact binaries
2015-07-26 14:33:49 +00:00
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Store the function including any extra state it might have (e.g. a lambda capture object) */
operators should return NotImplemented given unsupported input (fixes #393)
2016-09-10 06:28:37 +00:00
auto rec = make_function_record();
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/* Store the capture object directly in the function record if there is enough space */
if (sizeof(capture) <= sizeof(rec->data)) {
avoid C++ -> Python -> C++ overheads when passing around function objects
2016-07-10 08:13:18 +00:00
/* Without these pragmas, GCC warns that there might not be
enough space to use the placement new operator. However, the
'if' statement above ensures that this is the case. */
Only disable placement-new warning under gcc >= 6 Otherwise this would create unknown option warnings under g++ < 6.
2016-07-07 20:26:04 +00:00
#if defined(__GNUG__) && !defined(__clang__) && __GNUC__ >= 6
Disable -Wplacement-new warning false alarm GCC-6 adds a -Wplacement-new warning that warns for placement-new into a space that is too small, which is sometimes being triggered here (e.g. example5 always generates the warning under g++-6). It's a false warning, however: the line immediately before just checked the size, and so this line is never going to actually be reached in the cases where the GCC warning is being triggered. This localizes the warning disabling just to this one spot as there are other placement-new uses in pybind11 where this warning could warn about legitimate future problems.
2016-07-07 20:11:42 +00:00
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wplacement-new"
#endif
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
new ((capture *) &rec->data) capture { std::forward<Func>(f) };
Only disable placement-new warning under gcc >= 6 Otherwise this would create unknown option warnings under g++ < 6.
2016-07-07 20:26:04 +00:00
#if defined(__GNUG__) && !defined(__clang__) && __GNUC__ >= 6
Disable -Wplacement-new warning false alarm GCC-6 adds a -Wplacement-new warning that warns for placement-new into a space that is too small, which is sometimes being triggered here (e.g. example5 always generates the warning under g++-6). It's a false warning, however: the line immediately before just checked the size, and so this line is never going to actually be reached in the cases where the GCC warning is being triggered. This localizes the warning disabling just to this one spot as there are other placement-new uses in pybind11 where this warning could warn about legitimate future problems.
2016-07-07 20:11:42 +00:00
# pragma GCC diagnostic pop
#endif
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
if (!std::is_trivially_destructible<Func>::value)
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
rec->free_data = [](function_record *r) { ((capture *) &r->data)->~capture(); };
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
} else {
rec->data[0] = new capture { std::forward<Func>(f) };
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
rec->free_data = [](function_record *r) { delete ((capture *) r->data[0]); };
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
}
install a cleanup handler for nontrivial lambda closures
2015-10-13 15:37:25 +00:00
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/* Type casters for the function arguments and return value */
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
using cast_in = argument_loader<Args...>;
using cast_out = make_caster<
conditional_t<std::is_void<Return>::value, void_type, Return>
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
>;
generate more compact binaries
2015-07-26 14:33:49 +00:00
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
static_assert(expected_num_args<Extra...>(sizeof...(Args), cast_in::has_args, cast_in::has_kwargs),
Error message wording tweak py::arg() doesn't only specify named arguments anymore, so the error message was misleading (e.g. when using `py::arg().noconvert()` and forgetting `py::arg()` for a second positional argument).
2017-03-19 15:36:18 +00:00
"The number of argument annotations does not match the number of function arguments");
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Dispatch code which converts function arguments and performs the actual function call */
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
rec->impl = [](function_call &call) -> handle {
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
cast_in args_converter;
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Try to cast the function arguments into the C++ domain */
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (!args_converter.load_args(call))
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
return PYBIND11_TRY_NEXT_OVERLOAD;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Invoke call policy pre-call hook */
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
process_attributes<Extra...>::precall(call);
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
/* Get a pointer to the capture object */
Avoid C-style const casts (#659) * Avoid C-style const casts Replace C-style casts that discard `const` with `const_cast` (and, where necessary, `reinterpret_cast` as well). * Warn about C-style const-discarding casts Change pybind11_enable_warnings to also enable `-Wcast-qual` (warn if a C-style cast discards `const`) by default. The previous commit should have gotten rid of all of these (at least, all the ones that tripped in my build, which included the tests), and this should discourage more from newly appearing.
2017-02-08 22:43:08 +00:00
auto data = (sizeof(capture) <= sizeof(call.func.data)
? &call.func.data : call.func.data[0]);
capture *cap = const_cast<capture *>(reinterpret_cast<const capture *>(data));
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
Add an ability to avoid forcing rvp::move Eigen::Ref objects, when returned, are almost always returned as rvalues; what's important is the data they reference, not the outer shell, and so we want to be able to use `::copy`, `::reference_internal`, etc. to refer to the data the Eigen::Ref references (in the following commits), rather than the Eigen::Ref instance itself. This moves the policy override into a struct so that code that wants to avoid it (or wants to provide some other Return-type-conditional override) can create a specialization of return_value_policy_override<Return> in order to override the override. This lets an Eigen::Ref-returning function be bound with `rvp::copy`, for example, to specify that the data should be copied into a new numpy array rather than referenced, or `rvp::reference_internal` to indicate that it should be referenced, but a keep-alive used (actually, we used the array's `base` rather than a py::keep_alive in such a case, but it accomplishes the same thing).
2017-01-20 05:59:26 +00:00
/* Override policy for rvalues -- usually to enforce rvp::move on an rvalue */
stl.h: propagate return value policies to type-specific casters (#1455) * stl.h: propagate return value policies to type-specific casters Return value policies for containers like those handled in in 'stl.h' are currently broken. The problem is that detail::return_value_policy_override<C>::policy() always returns 'move' when given a non-pointer/reference type, e.g. 'std::vector<...>'. This is sensible behavior for custom types that are exposed via 'py::class_<>', but it does not make sense for types that are handled by other type casters (STL containers, Eigen matrices, etc.). This commit changes the behavior so that detail::return_value_policy_override only becomes active when the type caster derives from type_caster_generic. Furthermore, the override logic is called recursively in STL type casters to enable key/value-specific behavior.
2018-07-17 14:56:26 +00:00
return_value_policy policy = return_value_policy_override<Return>::policy(call.func.policy);
Always use return_value_policy::move for rvalues (#510) Fixes #509. The move policy was already set for rvalues in PR #473, but this only applied to directly cast user-defined types. The problem is that STL containers cast values indirectly and the rvalue information is lost. Therefore the move policy was not set correctly. This commit fixes it. This also makes an additional adjustment to remove the `copy` policy exception: rvalues now always use the `move` policy. This is also safe for copy-only rvalues because the `move` policy has an internal fallback to copying.
2016-11-20 04:31:02 +00:00
Add a scope guard call policy ```c++ m.def("foo", foo, py::call_guard<T>()); ``` is equivalent to: ```c++ m.def("foo", [](args...) { T scope_guard; return foo(args...); // forwarded arguments }); ```
2017-03-16 10:22:26 +00:00
/* Function scope guard -- defaults to the compile-to-nothing `void_type` */
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
using Guard = extract_guard_t<Extra...>;
Add a scope guard call policy ```c++ m.def("foo", foo, py::call_guard<T>()); ``` is equivalent to: ```c++ m.def("foo", [](args...) { T scope_guard; return foo(args...); // forwarded arguments }); ```
2017-03-16 10:22:26 +00:00
avoid C++ -> Python -> C++ overheads when passing around function objects
2016-07-10 08:13:18 +00:00
/* Perform the function call */
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
handle result = cast_out::cast(
std::move(args_converter).template call<Return, Guard>(cap->f), policy, call.parent);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Invoke call policy post-call hook */
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
process_attributes<Extra...>::postcall(call, result);
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
keep_alive call policy (analogous to Boost.Python's with_custodian_and_ward, fixes #62)
2016-01-17 21:36:39 +00:00
return result;
generate more compact binaries
2015-07-26 14:33:49 +00:00
};
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Process any user-provided function attributes */
Remove unnecessary `detail::` This function already has a `using namespace detail`, so all the `detail::` qualifications are not needed.
2018-01-12 16:06:46 +00:00
process_attributes<Extra...>::init(extra..., rec);
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Generate a readable signature describing the function's arguments and return value types */
Use semi-constexpr signatures on MSVC MSCV does not allow `&typeid(T)` in constexpr contexts, but the string part of the type signature can still be constexpr. In order to avoid `typeid` as long as possible, `descr` is modified to collect type information as template parameters instead of constexpr `typeid`. The actual `std::type_info` pointers are only collected in the end, as a `constexpr` (gcc/clang) or regular (MSVC) function call. Not only does it significantly reduce binary size on MSVC, gcc/clang benefit a little bit as well, since they can skip some intermediate `std::type_info*` arrays.
2017-07-02 10:52:00 +00:00
static constexpr auto signature = _("(") + cast_in::arg_names + _(") -> ") + cast_out::name;
PYBIND11_DESCR_CONSTEXPR auto types = decltype(signature)::types();
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Register the function with Python from generic (non-templated) code */
Use semi-constexpr signatures on MSVC MSCV does not allow `&typeid(T)` in constexpr contexts, but the string part of the type signature can still be constexpr. In order to avoid `typeid` as long as possible, `descr` is modified to collect type information as template parameters instead of constexpr `typeid`. The actual `std::type_info` pointers are only collected in the end, as a `constexpr` (gcc/clang) or regular (MSVC) function call. Not only does it significantly reduce binary size on MSVC, gcc/clang benefit a little bit as well, since they can skip some intermediate `std::type_info*` arrays.
2017-07-02 10:52:00 +00:00
initialize_generic(rec, signature.text, types.data(), sizeof...(Args));
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
if (cast_in::has_args) rec->has_args = true;
if (cast_in::has_kwargs) rec->has_kwargs = true;
avoid C++ -> Python -> C++ overheads when passing around function objects
2016-07-10 08:13:18 +00:00
/* Stash some additional information used by an important optimization in 'functional.h' */
Revert noexcept deduction in favour of better SFINAE on lambda functions (#677) noexcept deduction, added in PR #555, doesn't work with clang's -std=c++1z; and while it works with g++, it isn't entirely clear to me that it is required to work in C++17. What should work, however, is that C++17 allows implicit conversion of a `noexcept(true)` function pointer to a `noexcept(false)` (i.e. default, noexcept-not-specified) function pointer. That was breaking in pybind11 because the cpp_function template used for lambdas provided a better match (i.e. without requiring an implicit conversion), but it then failed. This commit takes a different approach of using SFINAE on the lambda function to prevent it from matching a non-lambda object, which then gets implicit conversion from a `noexcept` function pointer to a `noexcept(false)` function pointer. This much nicer solution also gets rid of the C++17 NOEXCEPT macros, and works in both clang and g++.
2017-02-17 11:56:41 +00:00
using FunctionType = Return (*)(Args...);
avoid C++ -> Python -> C++ overheads when passing around function objects
2016-07-10 08:13:18 +00:00
constexpr bool is_function_ptr =
std::is_convertible<Func, FunctionType>::value &&
sizeof(capture) == sizeof(void *);
if (is_function_ptr) {
rec->is_stateless = true;
Avoid C-style const casts (#659) * Avoid C-style const casts Replace C-style casts that discard `const` with `const_cast` (and, where necessary, `reinterpret_cast` as well). * Warn about C-style const-discarding casts Change pybind11_enable_warnings to also enable `-Wcast-qual` (warn if a C-style cast discards `const`) by default. The previous commit should have gotten rid of all of these (at least, all the ones that tripped in my build, which included the tests), and this should discourage more from newly appearing.
2017-02-08 22:43:08 +00:00
rec->data[1] = const_cast<void *>(reinterpret_cast<const void *>(&typeid(FunctionType)));
avoid C++ -> Python -> C++ overheads when passing around function objects
2016-07-10 08:13:18 +00:00
}
nicer code separation, cleanup logic, std::function type caster
2015-07-30 13:29:00 +00:00
}
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/// Register a function call with Python (generic non-templated code goes here)
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
void initialize_generic(detail::function_record *rec, const char *text,
Use generic arg names for functions without explicitly named arguments Example signatures (old => new): foo(int) => foo(arg0: int) bar(Object, int) => bar(self: Object, arg0: int) The change makes the signatures uniform for named and unnamed arguments and it helps static analysis tools reconstruct function signatures from docstrings. This also tweaks the signature whitespace style to better conform to PEP 8 for annotations and default arguments: " : " => ": " " = " => "="
2016-07-31 18:03:18 +00:00
const std::type_info *const *types, size_t args) {
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
/* Create copies of all referenced C-style strings */
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
rec->name = strdup(rec->name ? rec->name : "");
if (rec->doc) rec->doc = strdup(rec->doc);
for (auto &a: rec->args) {
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
if (a.name)
a.name = strdup(a.name);
if (a.descr)
a.descr = strdup(a.descr);
else if (a.value)
Extend attribute and item accessor interface using object_api
2016-09-08 15:02:04 +00:00
a.descr = strdup(a.value.attr("__repr__")().cast<std::string>().c_str());
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
}
avoid C++ -> Python -> C++ overheads when passing around function objects
2016-07-10 08:13:18 +00:00
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
rec->is_constructor = !strcmp(rec->name, "__init__") || !strcmp(rec->name, "__setstate__");
Show a deprecation warning for old-style `__init__` and `__setstate__` The warning is shown at module initialization time (on import, not when the functions are called). It's only visible when compiled in debug mode.
2017-08-24 00:46:07 +00:00
#if !defined(NDEBUG) && !defined(PYBIND11_DISABLE_NEW_STYLE_INIT_WARNING)
if (rec->is_constructor && !rec->is_new_style_constructor) {
const auto class_name = std::string(((PyTypeObject *) rec->scope.ptr())->tp_name);
const auto func_name = std::string(rec->name);
PyErr_WarnEx(
PyExc_FutureWarning,
("pybind11-bound class '" + class_name + "' is using an old-style "
"placement-new '" + func_name + "' which has been deprecated. See "
"the upgrade guide in pybind11's docs. This message is only visible "
"when compiled in debug mode.").c_str(), 0
);
}
#endif
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
/* Generate a proper function signature */
std::string signature;
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
size_t type_index = 0, arg_index = 0;
for (auto *pc = text; *pc != '\0'; ++pc) {
const auto c = *pc;
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
if (c == '{') {
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
// Write arg name for everything except *args and **kwargs.
if (*(pc + 1) == '*')
continue;
if (arg_index < rec->args.size() && rec->args[arg_index].name) {
signature += rec->args[arg_index].name;
} else if (arg_index == 0 && rec->is_method) {
signature += "self";
} else {
signature += "arg" + std::to_string(arg_index - (rec->is_method ? 1 : 0));
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
}
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
signature += ": ";
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
} else if (c == '}') {
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
// Write default value if available.
if (arg_index < rec->args.size() && rec->args[arg_index].descr) {
Add spaces around "=" in signature repr. PEP8 indicates (correctly, IMO) that when an annotation is present, the signature should include spaces around the equal sign, i.e. def f(x: int = 1): ... instead of def f(x: int=1): ... (in the latter case the equal appears to bind to the type, not to the argument). pybind11 signatures always includes a type annotation so we can always add the spaces.
2017-11-27 04:00:35 +00:00
signature += " = ";
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
signature += rec->args[arg_index].descr;
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
}
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
arg_index++;
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
} else if (c == '%') {
const std::type_info *t = types[type_index++];
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
if (!t)
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("Internal error while parsing type signature (1)");
Use detail::get_type_info() wherever sensible This reduces direct access to internals.registered_types_cpp to just a few places.
2016-10-23 14:43:03 +00:00
if (auto tinfo = detail::get_type_info(*t)) {
__qualname__ and nested class naming fixes (#1171) A few fixes related to how we set `__qualname__` and how we show the type name in function signatures: - `__qualname__` isn't supposed to have the module name at the beginning, but we've been putting it there. This removes it, while keeping the `Nested.Class` name chaining. - print `__module__.__qualname__` rather than `type->tp_name`; the latter doesn't work properly for nested classes, so we would get `module.B` rather than `module.A.B` for a class `B` with parent `A`. This also unifies the Python 3 and PyPy code. Fixes #1166. - This now sets a `__qualname__` attribute on the type (as would happen in Python 3.3+) for Python <3.3, including PyPy. While not particularly important to have in earlier Python versions, it's useful for us to be able to extracted the nested name, which is why `__qualname__` was invented in the first place. - Added tests for the above.
2017-11-07 16:33:05 +00:00
handle th((PyObject *) tinfo->type);
signature +=
th.attr("__module__").cast<std::string>() + "." +
th.attr("__qualname__").cast<std::string>(); // Python 3.3+, but we backport it to earlier versions
Reduce binary size overhead of new-style constructors The lookup of the `self` type and value pointer are moved out of template code and into `dispatcher`. This brings down the binary size of constructors back to the level of the old placement-new approach. (It also avoids a second lookup for `init_instance`.) With this implementation, mixing old- and new-style constructors in the same overload set may result in some runtime overhead for temporary allocations/deallocations, but this should be fine as old style constructors are phased out.
2017-08-17 00:01:32 +00:00
} else if (rec->is_new_style_constructor && arg_index == 0) {
// A new-style `__init__` takes `self` as `value_and_holder`.
// Rewrite it to the proper class type.
__qualname__ and nested class naming fixes (#1171) A few fixes related to how we set `__qualname__` and how we show the type name in function signatures: - `__qualname__` isn't supposed to have the module name at the beginning, but we've been putting it there. This removes it, while keeping the `Nested.Class` name chaining. - print `__module__.__qualname__` rather than `type->tp_name`; the latter doesn't work properly for nested classes, so we would get `module.B` rather than `module.A.B` for a class `B` with parent `A`. This also unifies the Python 3 and PyPy code. Fixes #1166. - This now sets a `__qualname__` attribute on the type (as would happen in Python 3.3+) for Python <3.3, including PyPy. While not particularly important to have in earlier Python versions, it's useful for us to be able to extracted the nested name, which is why `__qualname__` was invented in the first place. - Added tests for the above.
2017-11-07 16:33:05 +00:00
signature +=
rec->scope.attr("__module__").cast<std::string>() + "." +
rec->scope.attr("__qualname__").cast<std::string>();
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
} else {
std::string tname(t->name());
detail::clean_type_id(tname);
signature += tname;
}
} else {
signature += c;
}
}
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
if (arg_index != args || types[type_index] != nullptr)
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("Internal error while parsing type signature (2)");
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
#if PY_MAJOR_VERSION < 3
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
if (strcmp(rec->name, "__next__") == 0) {
std::free(rec->name);
rec->name = strdup("next");
support __bool__ on Python 2.x and 3.x
2016-05-16 16:52:46 +00:00
} else if (strcmp(rec->name, "__bool__") == 0) {
std::free(rec->name);
rec->name = strdup("__nonzero__");
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
}
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
#endif
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
rec->signature = strdup(signature.c_str());
rec->args.shrink_to_fit();
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
rec->nargs = (std::uint16_t) args;
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
Don't let PyInstanceMethod hide itself Python 3's `PyInstanceMethod_Type` hides itself via its `tp_descr_get`, which prevents aliasing methods via `cls.attr("m2") = cls.attr("m1")`: instead the `tp_descr_get` returns a plain function, when called on a class, or a `PyMethod`, when called on an instance. Override that behaviour for pybind11 types with a special bypass for `PyInstanceMethod_Types`.
2017-04-17 00:30:52 +00:00
if (rec->sibling && PYBIND11_INSTANCE_METHOD_CHECK(rec->sibling.ptr()))
rec->sibling = PYBIND11_INSTANCE_METHOD_GET_FUNCTION(rec->sibling.ptr());
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
detail::function_record *chain = nullptr, *chain_start = rec;
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
if (rec->sibling) {
if (PyCFunction_Check(rec->sibling.ptr())) {
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
auto rec_capsule = reinterpret_borrow<capsule>(PyCFunction_GET_SELF(rec->sibling.ptr()));
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
chain = (detail::function_record *) rec_capsule;
/* Never append a method to an overload chain of a parent class;
instead, hide the parent's overloads in this case */
Deprecate handle::operator== in favor of object_api::is
2017-02-08 00:01:56 +00:00
if (!chain->scope.is(rec->scope))
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
chain = nullptr;
}
// Don't trigger for things like the default __init__, which are wrapper_descriptors that we are intentionally replacing
else if (!rec->sibling.is_none() && rec->name[0] != '_')
pybind11_fail("Cannot overload existing non-function object \"" + std::string(rec->name) +
"\" with a function of the same name");
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
if (!chain) {
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* No existing overload was found, create a new function object */
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
rec->def = new PyMethodDef();
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
std::memset(rec->def, 0, sizeof(PyMethodDef));
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
rec->def->ml_name = rec->name;
Silence GCC8's -Wcast-function-type. (#1396) * Silence GCC8's -Wcast-function-type. See https://bugs.python.org/issue33012 and PRs linked therein.
2018-06-24 13:38:09 +00:00
rec->def->ml_meth = reinterpret_cast<PyCFunction>(reinterpret_cast<void (*) (void)>(*dispatcher));
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
rec->def->ml_flags = METH_VARARGS | METH_KEYWORDS;
set __module__ attribute of functions (fixes #95)
2016-02-04 22:02:07 +00:00
Nicer API to pass py::capsule destructor (#752) * nicer py::capsule destructor mechanism * added destructor-only version of capsule & tests * added documentation for module destructors (fixes #733)
2017-03-22 21:04:00 +00:00
capsule rec_capsule(rec, [](void *ptr) {
destruct((detail::function_record *) ptr);
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
});
set __module__ attribute of functions (fixes #95)
2016-02-04 22:02:07 +00:00
object scope_module;
if (rec->scope) {
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
if (hasattr(rec->scope, "__module__")) {
scope_module = rec->scope.attr("__module__");
} else if (hasattr(rec->scope, "__name__")) {
scope_module = rec->scope.attr("__name__");
}
set __module__ attribute of functions (fixes #95)
2016-02-04 22:02:07 +00:00
}
m_ptr = PyCFunction_NewEx(rec->def, rec_capsule.ptr(), scope_module.ptr());
Initial commit
2015-07-05 18:05:44 +00:00
if (!m_ptr)
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("cpp_function::cpp_function(): Could not allocate function object");
Initial commit
2015-07-05 18:05:44 +00:00
} else {
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Append at the end of the overload chain */
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
m_ptr = rec->sibling.ptr();
Initial commit
2015-07-05 18:05:44 +00:00
inc_ref();
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
chain_start = chain;
Don't allow mixed static/non-static overloads We currently fail at runtime when trying to call a method that is overloaded with both static and non-static methods. This is something python won't allow: the object is either a function or an instance, and can't be both.
2017-04-17 02:31:13 +00:00
if (chain->is_method != rec->is_method)
pybind11_fail("overloading a method with both static and instance methods is not supported; "
#if defined(NDEBUG)
"compile in debug mode for more details"
#else
"error while attempting to bind " + std::string(rec->is_method ? "instance" : "static") + " method " +
std::string(pybind11::str(rec->scope.attr("__name__"))) + "." + std::string(rec->name) + signature
#endif
);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
while (chain->next)
chain = chain->next;
chain->next = rec;
Initial commit
2015-07-05 18:05:44 +00:00
}
nicer code separation, cleanup logic, std::function type caster
2015-07-30 13:29:00 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
std::string signatures;
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
int index = 0;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Create a nice pydoc rec including all signatures and
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
docstrings of the functions in the overload chain */
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (chain && options::show_function_signatures()) {
Add generic signature for overloads
2016-03-08 21:42:12 +00:00
// First a generic signature
signatures += rec->name;
signatures += "(*args, **kwargs)\n";
signatures += "Overloaded function.\n\n";
}
// Then specific overload signatures
Fix extra docstring newlines under `options.disable_function_signatures()` When using pybind::options to disable function signatures, user-defined docstrings only get appended if they exist, but newlines were getting appended unconditionally, so the docstring could end up with blank lines (depending on which overloads, in particular, provided docstrings). This commit suppresses the empty lines by only adding newlines for overloads when needed.
2017-03-08 17:32:42 +00:00
bool first_user_def = true;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
for (auto it = chain_start; it != nullptr; it = it->next) {
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (options::show_function_signatures()) {
Fix extra docstring newlines under `options.disable_function_signatures()` When using pybind::options to disable function signatures, user-defined docstrings only get appended if they exist, but newlines were getting appended unconditionally, so the docstring could end up with blank lines (depending on which overloads, in particular, provided docstrings). This commit suppresses the empty lines by only adding newlines for overloads when needed.
2017-03-08 17:32:42 +00:00
if (index > 0) signatures += "\n";
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (chain)
signatures += std::to_string(++index) + ". ";
signatures += rec->name;
signatures += it->signature;
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
signatures += "\n";
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
}
if (it->doc && strlen(it->doc) > 0 && options::show_user_defined_docstrings()) {
Fix extra docstring newlines under `options.disable_function_signatures()` When using pybind::options to disable function signatures, user-defined docstrings only get appended if they exist, but newlines were getting appended unconditionally, so the docstring could end up with blank lines (depending on which overloads, in particular, provided docstrings). This commit suppresses the empty lines by only adding newlines for overloads when needed.
2017-03-08 17:32:42 +00:00
// If we're appending another docstring, and aren't printing function signatures, we
// need to append a newline first:
if (!options::show_function_signatures()) {
if (first_user_def) first_user_def = false;
else signatures += "\n";
}
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (options::show_function_signatures()) signatures += "\n";
Revert "trim docstrings (closes #112)" This reverts commit b3ef54a5449f2ec42e1d091b208ffb12258e755a.
2016-02-28 22:52:37 +00:00
signatures += it->doc;
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (options::show_function_signatures()) signatures += "\n";
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Install docstring */
Initial commit
2015-07-05 18:05:44 +00:00
PyCFunctionObject *func = (PyCFunctionObject *) m_ptr;
if (func->m_ml->ml_doc)
Avoid C-style const casts (#659) * Avoid C-style const casts Replace C-style casts that discard `const` with `const_cast` (and, where necessary, `reinterpret_cast` as well). * Warn about C-style const-discarding casts Change pybind11_enable_warnings to also enable `-Wcast-qual` (warn if a C-style cast discards `const`) by default. The previous commit should have gotten rid of all of these (at least, all the ones that tripped in my build, which included the tests), and this should discourage more from newly appearing.
2017-02-08 22:43:08 +00:00
std::free(const_cast<char *>(func->m_ml->ml_doc));
Initial commit
2015-07-05 18:05:44 +00:00
func->m_ml->ml_doc = strdup(signatures.c_str());
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
replace redundant function_record->class_ field with 1 bit
2016-11-20 04:27:05 +00:00
if (rec->is_method) {
m_ptr = PYBIND11_INSTANCE_METHOD_NEW(m_ptr, rec->scope.ptr());
Initial commit
2015-07-05 18:05:44 +00:00
if (!m_ptr)
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("cpp_function::cpp_function(): Could not allocate instance method object");
Initial commit
2015-07-05 18:05:44 +00:00
Py_DECREF(func);
}
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/// When a cpp_function is GCed, release any memory allocated by pybind11
static void destruct(detail::function_record *rec) {
while (rec) {
detail::function_record *next = rec->next;
if (rec->free_data)
redesigned cpp_function constructor; significant space savings
2016-05-10 14:05:03 +00:00
rec->free_data(rec);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
std::free((char *) rec->name);
std::free((char *) rec->doc);
std::free((char *) rec->signature);
for (auto &arg: rec->args) {
Avoid C-style const casts (#659) * Avoid C-style const casts Replace C-style casts that discard `const` with `const_cast` (and, where necessary, `reinterpret_cast` as well). * Warn about C-style const-discarding casts Change pybind11_enable_warnings to also enable `-Wcast-qual` (warn if a C-style cast discards `const`) by default. The previous commit should have gotten rid of all of these (at least, all the ones that tripped in my build, which included the tests), and this should discourage more from newly appearing.
2017-02-08 22:43:08 +00:00
std::free(const_cast<char *>(arg.name));
std::free(const_cast<char *>(arg.descr));
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
arg.value.dec_ref();
}
if (rec->def) {
Avoid C-style const casts (#659) * Avoid C-style const casts Replace C-style casts that discard `const` with `const_cast` (and, where necessary, `reinterpret_cast` as well). * Warn about C-style const-discarding casts Change pybind11_enable_warnings to also enable `-Wcast-qual` (warn if a C-style cast discards `const`) by default. The previous commit should have gotten rid of all of these (at least, all the ones that tripped in my build, which included the tests), and this should discourage more from newly appearing.
2017-02-08 22:43:08 +00:00
std::free(const_cast<char *>(rec->def->ml_doc));
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
delete rec->def;
}
delete rec;
rec = next;
}
}
/// Main dispatch logic for calls to functions bound using pybind11
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
static PyObject *dispatcher(PyObject *self, PyObject *args_in, PyObject *kwargs_in) {
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
using namespace detail;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Iterator over the list of potentially admissible overloads */
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
const function_record *overloads = (function_record *) PyCapsule_GetPointer(self, nullptr),
*it = overloads;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Need to know how many arguments + keyword arguments there are to pick the right overload */
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
const size_t n_args_in = (size_t) PyTuple_GET_SIZE(args_in);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
handle parent = n_args_in > 0 ? PyTuple_GET_ITEM(args_in, 0) : nullptr,
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
result = PYBIND11_TRY_NEXT_OVERLOAD;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
Reduce binary size overhead of new-style constructors The lookup of the `self` type and value pointer are moved out of template code and into `dispatcher`. This brings down the binary size of constructors back to the level of the old placement-new approach. (It also avoids a second lookup for `init_instance`.) With this implementation, mixing old- and new-style constructors in the same overload set may result in some runtime overhead for temporary allocations/deallocations, but this should be fine as old style constructors are phased out.
2017-08-17 00:01:32 +00:00
auto self_value_and_holder = value_and_holder();
if (overloads->is_constructor) {
const auto tinfo = get_type_info((PyTypeObject *) overloads->scope.ptr());
const auto pi = reinterpret_cast<instance *>(parent.ptr());
self_value_and_holder = pi->get_value_and_holder(tinfo, false);
if (!self_value_and_holder.type || !self_value_and_holder.inst) {
PyErr_SetString(PyExc_TypeError, "__init__(self, ...) called with invalid `self` argument");
return nullptr;
}
// If this value is already registered it must mean __init__ is invoked multiple times;
// we really can't support that in C++, so just ignore the second __init__.
if (self_value_and_holder.instance_registered())
return none().release().ptr();
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
try {
Prefer non-converting argument overloads This changes the function dispatching code for overloaded functions into a two-pass procedure where we first try all overloads with `convert=false` for all arguments. If no function calls succeeds in the first pass, we then try a second pass where we allow arguments to have `convert=true` (unless, of course, the argument was explicitly specified with `py::arg().noconvert()`). For non-overloaded methods, the two-pass procedure is skipped (we just make the overload-allowed call). The second pass is also skipped if it would result in the same thing (i.e. where all arguments are `.noconvert()` arguments).
2017-02-03 23:25:34 +00:00
// We do this in two passes: in the first pass, we load arguments with `convert=false`;
// in the second, we allow conversion (except for arguments with an explicit
// py::arg().noconvert()). This lets us prefer calls without conversion, with
// conversion as a fallback.
std::vector<function_call> second_pass;
// However, if there are no overloads, we can just skip the no-convert pass entirely
const bool overloaded = it != nullptr && it->next != nullptr;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
for (; it != nullptr; it = it->next) {
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* For each overload:
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
1. Copy all positional arguments we were given, also checking to make sure that
named positional arguments weren't *also* specified via kwarg.
Very minor code style changes, and fixed a typo
2017-01-31 16:23:53 +00:00
2. If we weren't given enough, try to make up the omitted ones by checking
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
whether they were provided by a kwarg matching the `py::arg("name")` name. If
so, use it (and remove it from kwargs; if not, see if the function binding
provided a default that we can use.
3. Ensure that either all keyword arguments were "consumed", or that the function
takes a kwargs argument to accept unconsumed kwargs.
4. Any positional arguments still left get put into a tuple (for args), and any
leftover kwargs get put into a dict.
5. Pack everything into a vector; if we have py::args or py::kwargs, they are an
extra tuple or dict at the end of the positional arguments.
6. Call the function call dispatcher (function_record::impl)
If one of these fail, move on to the next overload and keep trying until we get a
result other than PYBIND11_TRY_NEXT_OVERLOAD.
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
*/
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
const function_record &func = *it;
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
size_t pos_args = func.nargs; // Number of positional arguments that we need
if (func.has_args) --pos_args; // (but don't count py::args
if (func.has_kwargs) --pos_args; // or py::kwargs)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
if (!func.has_args && n_args_in > pos_args)
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
continue; // Too many arguments for this overload
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
if (n_args_in < pos_args && func.args.size() < pos_args)
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
continue; // Not enough arguments given, and not enough defaults to fill in the blanks
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
function_call call(func, parent);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
size_t args_to_copy = std::min(pos_args, n_args_in);
size_t args_copied = 0;
Reduce binary size overhead of new-style constructors The lookup of the `self` type and value pointer are moved out of template code and into `dispatcher`. This brings down the binary size of constructors back to the level of the old placement-new approach. (It also avoids a second lookup for `init_instance`.) With this implementation, mixing old- and new-style constructors in the same overload set may result in some runtime overhead for temporary allocations/deallocations, but this should be fine as old style constructors are phased out.
2017-08-17 00:01:32 +00:00
// 0. Inject new-style `self` argument
if (func.is_new_style_constructor) {
// The `value` may have been preallocated by an old-style `__init__`
// if it was a preceding candidate for overload resolution.
if (self_value_and_holder)
self_value_and_holder.type->dealloc(self_value_and_holder);
Fix application of keep_alive policy to constructors (regression)
2017-09-04 11:49:19 +00:00
call.init_self = PyTuple_GET_ITEM(args_in, 0);
Reduce binary size overhead of new-style constructors The lookup of the `self` type and value pointer are moved out of template code and into `dispatcher`. This brings down the binary size of constructors back to the level of the old placement-new approach. (It also avoids a second lookup for `init_instance`.) With this implementation, mixing old- and new-style constructors in the same overload set may result in some runtime overhead for temporary allocations/deallocations, but this should be fine as old style constructors are phased out.
2017-08-17 00:01:32 +00:00
call.args.push_back(reinterpret_cast<PyObject *>(&self_value_and_holder));
call.args_convert.push_back(false);
++args_copied;
}
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
// 1. Copy any position arguments given.
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
bool bad_arg = false;
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
for (; args_copied < args_to_copy; ++args_copied) {
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
const argument_record *arg_rec = args_copied < func.args.size() ? &func.args[args_copied] : nullptr;
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
if (kwargs_in && arg_rec && arg_rec->name && PyDict_GetItemString(kwargs_in, arg_rec->name)) {
bad_arg = true;
Make bad kwarg arguments try next overload Fixes #688. My (commented) assumption that such an error is "highly likely to be a caller mistake" was proven false by #688.
2017-02-24 00:54:53 +00:00
break;
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
}
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
handle arg(PyTuple_GET_ITEM(args_in, args_copied));
if (arg_rec && !arg_rec->none && arg.is_none()) {
bad_arg = true;
break;
}
call.args.push_back(arg);
call.args_convert.push_back(arg_rec ? arg_rec->convert : true);
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
}
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
if (bad_arg)
Make bad kwarg arguments try next overload Fixes #688. My (commented) assumption that such an error is "highly likely to be a caller mistake" was proven false by #688.
2017-02-24 00:54:53 +00:00
continue; // Maybe it was meant for another overload (issue #688)
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
// We'll need to copy this if we steal some kwargs for defaults
dict kwargs = reinterpret_borrow<dict>(kwargs_in);
// 2. Check kwargs and, failing that, defaults that may help complete the list
if (args_copied < pos_args) {
bool copied_kwargs = false;
for (; args_copied < pos_args; ++args_copied) {
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
const auto &arg = func.args[args_copied];
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
handle value;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (kwargs_in && arg.name)
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
value = PyDict_GetItemString(kwargs.ptr(), arg.name);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
if (value) {
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
// Consume a kwargs value
if (!copied_kwargs) {
kwargs = reinterpret_steal<dict>(PyDict_Copy(kwargs.ptr()));
copied_kwargs = true;
}
PyDict_DelItemString(kwargs.ptr(), arg.name);
Very minor code style changes, and fixed a typo
2017-01-31 16:23:53 +00:00
} else if (arg.value) {
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
value = arg.value;
}
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (value) {
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
call.args.push_back(value);
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
call.args_convert.push_back(arg.convert);
}
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
else
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
break;
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
}
if (args_copied < pos_args)
continue; // Not enough arguments, defaults, or kwargs to fill the positional arguments
}
// 3. Check everything was consumed (unless we have a kwargs arg)
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (kwargs && kwargs.size() > 0 && !func.has_kwargs)
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
continue; // Unconsumed kwargs, but no py::kwargs argument to accept them
// 4a. If we have a py::args argument, create a new tuple with leftovers
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (func.has_args) {
Fix premature destruction of args/kwargs arguments The `py::args` or `py::kwargs` arguments aren't properly referenced when added to the function_call arguments list: their reference counts drop to zero if the first (non-converting) function call fails, which means they might be cleaned up before the second pass call runs. This commit adds a couple of extra `object`s to the `function_call` where we can stash a reference to them when needed to tie their lifetime to the function_call object's lifetime. (Credit to YannickJadoul for catching and proposing a fix in #1223).
2017-12-23 13:42:32 +00:00
tuple extra_args;
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
if (args_to_copy == 0) {
// We didn't copy out any position arguments from the args_in tuple, so we
// can reuse it directly without copying:
extra_args = reinterpret_borrow<tuple>(args_in);
Very minor code style changes, and fixed a typo
2017-01-31 16:23:53 +00:00
} else if (args_copied >= n_args_in) {
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
extra_args = tuple(0);
Very minor code style changes, and fixed a typo
2017-01-31 16:23:53 +00:00
} else {
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
size_t args_size = n_args_in - args_copied;
extra_args = tuple(args_size);
for (size_t i = 0; i < args_size; ++i) {
Simplify arg copying
2017-12-15 17:21:52 +00:00
extra_args[i] = PyTuple_GET_ITEM(args_in, args_copied + i);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
}
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
call.args.push_back(extra_args);
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
call.args_convert.push_back(false);
Fix premature destruction of args/kwargs arguments The `py::args` or `py::kwargs` arguments aren't properly referenced when added to the function_call arguments list: their reference counts drop to zero if the first (non-converting) function call fails, which means they might be cleaned up before the second pass call runs. This commit adds a couple of extra `object`s to the `function_call` where we can stash a reference to them when needed to tie their lifetime to the function_call object's lifetime. (Credit to YannickJadoul for catching and proposing a fix in #1223).
2017-12-23 13:42:32 +00:00
call.args_ref = std::move(extra_args);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
don't try to cast 'None' into a C++ lvalue reference
2016-05-01 12:42:20 +00:00
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
// 4b. If we have a py::kwargs, pass on any remaining kwargs
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (func.has_kwargs) {
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
if (!kwargs.ptr())
kwargs = dict(); // If we didn't get one, send an empty one
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
call.args.push_back(kwargs);
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
call.args_convert.push_back(false);
Fix premature destruction of args/kwargs arguments The `py::args` or `py::kwargs` arguments aren't properly referenced when added to the function_call arguments list: their reference counts drop to zero if the first (non-converting) function call fails, which means they might be cleaned up before the second pass call runs. This commit adds a couple of extra `object`s to the `function_call` where we can stash a reference to them when needed to tie their lifetime to the function_call object's lifetime. (Credit to YannickJadoul for catching and proposing a fix in #1223).
2017-12-23 13:42:32 +00:00
call.kwargs_ref = std::move(kwargs);
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
}
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
// 5. Put everything in a vector. Not technically step 5, we've been building it
// in `call.args` all along.
#if !defined(NDEBUG)
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (call.args.size() != func.nargs || call.args_convert.size() != func.nargs)
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
pybind11_fail("Internal error: function call dispatcher inserted wrong number of arguments!");
#endif
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
Prefer non-converting argument overloads This changes the function dispatching code for overloaded functions into a two-pass procedure where we first try all overloads with `convert=false` for all arguments. If no function calls succeeds in the first pass, we then try a second pass where we allow arguments to have `convert=true` (unless, of course, the argument was explicitly specified with `py::arg().noconvert()`). For non-overloaded methods, the two-pass procedure is skipped (we just make the overload-allowed call). The second pass is also skipped if it would result in the same thing (i.e. where all arguments are `.noconvert()` arguments).
2017-02-03 23:25:34 +00:00
std::vector<bool> second_pass_convert;
if (overloaded) {
// We're in the first no-convert pass, so swap out the conversion flags for a
// set of all-false flags. If the call fails, we'll swap the flags back in for
// the conversion-allowed call below.
second_pass_convert.resize(func.nargs, false);
call.args_convert.swap(second_pass_convert);
}
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
// 6. Call the function.
don't try to cast 'None' into a C++ lvalue reference
2016-05-01 12:42:20 +00:00
try {
Add a life support system for type_caster temporaries
2017-06-26 18:34:06 +00:00
loader_life_support guard{};
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
result = func.impl(call);
switched internal usage of cast_error exception to reference_cast_error
2016-07-01 14:07:35 +00:00
} catch (reference_cast_error &) {
don't try to cast 'None' into a C++ lvalue reference
2016-05-01 12:42:20 +00:00
result = PYBIND11_TRY_NEXT_OVERLOAD;
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
if (result.ptr() != PYBIND11_TRY_NEXT_OVERLOAD)
break;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
Prefer non-converting argument overloads This changes the function dispatching code for overloaded functions into a two-pass procedure where we first try all overloads with `convert=false` for all arguments. If no function calls succeeds in the first pass, we then try a second pass where we allow arguments to have `convert=true` (unless, of course, the argument was explicitly specified with `py::arg().noconvert()`). For non-overloaded methods, the two-pass procedure is skipped (we just make the overload-allowed call). The second pass is also skipped if it would result in the same thing (i.e. where all arguments are `.noconvert()` arguments).
2017-02-03 23:25:34 +00:00
if (overloaded) {
// The (overloaded) call failed; if the call has at least one argument that
// permits conversion (i.e. it hasn't been explicitly specified `.noconvert()`)
// then add this call to the list of second pass overloads to try.
for (size_t i = func.is_method ? 1 : 0; i < pos_args; i++) {
if (second_pass_convert[i]) {
// Found one: swap the converting flags back in and store the call for
// the second pass.
call.args_convert.swap(second_pass_convert);
second_pass.push_back(std::move(call));
break;
}
}
}
}
if (overloaded && !second_pass.empty() && result.ptr() == PYBIND11_TRY_NEXT_OVERLOAD) {
// The no-conversion pass finished without success, try again with conversion allowed
for (auto &call : second_pass) {
try {
Add a life support system for type_caster temporaries
2017-06-26 18:34:06 +00:00
loader_life_support guard{};
Prefer non-converting argument overloads This changes the function dispatching code for overloaded functions into a two-pass procedure where we first try all overloads with `convert=false` for all arguments. If no function calls succeeds in the first pass, we then try a second pass where we allow arguments to have `convert=true` (unless, of course, the argument was explicitly specified with `py::arg().noconvert()`). For non-overloaded methods, the two-pass procedure is skipped (we just make the overload-allowed call). The second pass is also skipped if it would result in the same thing (i.e. where all arguments are `.noconvert()` arguments).
2017-02-03 23:25:34 +00:00
result = call.func.impl(call);
} catch (reference_cast_error &) {
result = PYBIND11_TRY_NEXT_OVERLOAD;
}
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
if (result.ptr() != PYBIND11_TRY_NEXT_OVERLOAD) {
// The error reporting logic below expects 'it' to be valid, as it would be
// if we'd encountered this failure in the first-pass loop.
if (!result)
it = &call.func;
Prefer non-converting argument overloads This changes the function dispatching code for overloaded functions into a two-pass procedure where we first try all overloads with `convert=false` for all arguments. If no function calls succeeds in the first pass, we then try a second pass where we allow arguments to have `convert=true` (unless, of course, the argument was explicitly specified with `py::arg().noconvert()`). For non-overloaded methods, the two-pass procedure is skipped (we just make the overload-allowed call). The second pass is also skipped if it would result in the same thing (i.e. where all arguments are `.noconvert()` arguments).
2017-02-03 23:25:34 +00:00
break;
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
}
Prefer non-converting argument overloads This changes the function dispatching code for overloaded functions into a two-pass procedure where we first try all overloads with `convert=false` for all arguments. If no function calls succeeds in the first pass, we then try a second pass where we allow arguments to have `convert=true` (unless, of course, the argument was explicitly specified with `py::arg().noconvert()`). For non-overloaded methods, the two-pass procedure is skipped (we just make the overload-allowed call). The second pass is also skipped if it would result in the same thing (i.e. where all arguments are `.noconvert()` arguments).
2017-02-03 23:25:34 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
Make error_already_set fetch and hold the Python error This clears the Python error at the error_already_set throw site, thus allowing Python calls to be made in destructors which are triggered by the exception. This is preferable to the alternative, which would be guarding every Python API call with an error_scope. This effectively flips the behavior of error_already_set. Previously, it was assumed that the error stays in Python, so handling the exception in C++ would require explicitly calling PyErr_Clear(), but nothing was needed to propagate the error to Python. With this change, handling the error in C++ does not require a PyErr_Clear() call, but propagating the error to Python requires an explicit error_already_set::restore(). The change does not break old code which explicitly calls PyErr_Clear() for cleanup, which should be the majority of user code. The need for an explicit restore() call does break old code, but this should be mostly confined to the library and not user code.
2016-09-10 09:58:02 +00:00
} catch (error_already_set &e) {
e.restore();
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
return nullptr;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
} catch (...) {
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
/* When an exception is caught, give each registered exception
translator a chance to translate it to a Python exception
in reverse order of registration.
pybind11.h: minor cleanups (no functionality change)
2016-07-18 08:47:10 +00:00
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
A translator may choose to do one of the following:
pybind11.h: minor cleanups (no functionality change)
2016-07-18 08:47:10 +00:00
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
- catch the exception and call PyErr_SetString or PyErr_SetObject
to set a standard (or custom) Python exception, or
- do nothing and let the exception fall through to the next translator, or
- delegate translation to the next translator by throwing a new type of exception. */
pybind11.h: minor cleanups (no functionality change)
2016-07-18 08:47:10 +00:00
auto last_exception = std::current_exception();
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
auto &registered_exception_translators = get_internals().registered_exception_translators;
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
for (auto& translator : registered_exception_translators) {
try {
translator(last_exception);
} catch (...) {
last_exception = std::current_exception();
continue;
}
return nullptr;
}
PyErr_SetString(PyExc_SystemError, "Exception escaped from default exception translator!");
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
return nullptr;
}
Make TypeErrors more informative when an optional header is missing E.g. trying to convert a `list` to a `std::vector<int>` without including <pybind11/stl.h> will now raise an error with a note that suggests checking the headers. The note is only appended if `std::` is found in the function signature. This should only be the case when a header is missing. E.g. when stl.h is included, the signature would contain `List[int]` instead of `std::vector<int>` while using stl_bind.h would produce something like `MyVector`. Similarly for `std::map`/`Dict`, `complex`, `std::function`/`Callable`, etc. There's a possibility for false positives, but it's pretty low.
2017-09-09 18:21:34 +00:00
auto append_note_if_missing_header_is_suspected = [](std::string &msg) {
if (msg.find("std::") != std::string::npos) {
msg += "\n\n"
"Did you forget to `#include <pybind11/stl.h>`? Or <pybind11/complex.h>,\n"
"<pybind11/functional.h>, <pybind11/chrono.h>, etc. Some automatic\n"
"conversions are optional and require extra headers to be included\n"
"when compiling your pybind11 module.";
}
};
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
if (result.ptr() == PYBIND11_TRY_NEXT_OVERLOAD) {
operators should return NotImplemented given unsupported input (fixes #393)
2016-09-10 06:28:37 +00:00
if (overloads->is_operator)
return handle(Py_NotImplemented).inc_ref().ptr();
nicer error message for invalid function arguments
2016-09-12 02:44:37 +00:00
std::string msg = std::string(overloads->name) + "(): incompatible " +
std::string(overloads->is_constructor ? "constructor" : "function") +
" arguments. The following argument types are supported:\n";
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
int ctr = 0;
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
for (const function_record *it2 = overloads; it2 != nullptr; it2 = it2->next) {
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
msg += " "+ std::to_string(++ctr) + ". ";
Fix #283: don't print first arg of constructor This changes the exception error message of a bad-arguments error to suppress the constructor argument when the failure is a constructor. This changes both the "Invoked with: " output to omit the object instances, and rewrites the constructor signature to make it look like a constructor (changing the first argument to the object name, and removing the ' -> NoneType' return type.
2016-07-17 21:43:00 +00:00
bool wrote_sig = false;
if (overloads->is_constructor) {
Use generic arg names for functions without explicitly named arguments Example signatures (old => new): foo(int) => foo(arg0: int) bar(Object, int) => bar(self: Object, arg0: int) The change makes the signatures uniform for named and unnamed arguments and it helps static analysis tools reconstruct function signatures from docstrings. This also tweaks the signature whitespace style to better conform to PEP 8 for annotations and default arguments: " : " => ": " " = " => "="
2016-07-31 18:03:18 +00:00
// For a constructor, rewrite `(self: Object, arg0, ...) -> NoneType` as `Object(arg0, ...)`
Fix #283: don't print first arg of constructor This changes the exception error message of a bad-arguments error to suppress the constructor argument when the failure is a constructor. This changes both the "Invoked with: " output to omit the object instances, and rewrites the constructor signature to make it look like a constructor (changing the first argument to the object name, and removing the ' -> NoneType' return type.
2016-07-17 21:43:00 +00:00
std::string sig = it2->signature;
Use generic arg names for functions without explicitly named arguments Example signatures (old => new): foo(int) => foo(arg0: int) bar(Object, int) => bar(self: Object, arg0: int) The change makes the signatures uniform for named and unnamed arguments and it helps static analysis tools reconstruct function signatures from docstrings. This also tweaks the signature whitespace style to better conform to PEP 8 for annotations and default arguments: " : " => ": " " = " => "="
2016-07-31 18:03:18 +00:00
size_t start = sig.find('(') + 7; // skip "(self: "
Fix #283: don't print first arg of constructor This changes the exception error message of a bad-arguments error to suppress the constructor argument when the failure is a constructor. This changes both the "Invoked with: " output to omit the object instances, and rewrites the constructor signature to make it look like a constructor (changing the first argument to the object name, and removing the ' -> NoneType' return type.
2016-07-17 21:43:00 +00:00
if (start < sig.size()) {
// End at the , for the next argument
size_t end = sig.find(", "), next = end + 2;
size_t ret = sig.rfind(" -> ");
// Or the ), if there is no comma:
if (end >= sig.size()) next = end = sig.find(')');
if (start < end && next < sig.size()) {
msg.append(sig, start, end - start);
msg += '(';
msg.append(sig, next, ret - next);
wrote_sig = true;
}
}
}
if (!wrote_sig) msg += it2->signature;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
msg += "\n";
}
nicer error message for invalid function arguments
2016-09-12 02:44:37 +00:00
msg += "\nInvoked with: ";
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
auto args_ = reinterpret_borrow<tuple>(args_in);
Show kwargs in failed method invocation With the previous commit, output can be very confusing because you only see positional arguments in the "invoked with" line, but you can have a failure from kwargs as well (in particular, when a value is invalidly specified via both via positional and kwargs). This commits adds kwargs to the output, and updates the associated tests to match.
2017-02-24 02:04:46 +00:00
bool some_args = false;
pybind11.h: minor cleanups (no functionality change)
2016-07-18 08:47:10 +00:00
for (size_t ti = overloads->is_constructor ? 1 : 0; ti < args_.size(); ++ti) {
Show kwargs in failed method invocation With the previous commit, output can be very confusing because you only see positional arguments in the "invoked with" line, but you can have a failure from kwargs as well (in particular, when a value is invalidly specified via both via positional and kwargs). This commits adds kwargs to the output, and updates the associated tests to match.
2017-02-24 02:04:46 +00:00
if (!some_args) some_args = true;
else msg += ", ";
Changed "Invoked with" output to use repr() instead of str() (#518) This gives more informative output, often including the type (or at least some hint about the type).
2016-11-22 10:28:40 +00:00
msg += pybind11::repr(args_[ti]);
Increase available information on invocation error.
2016-05-24 07:19:35 +00:00
}
Show kwargs in failed method invocation With the previous commit, output can be very confusing because you only see positional arguments in the "invoked with" line, but you can have a failure from kwargs as well (in particular, when a value is invalidly specified via both via positional and kwargs). This commits adds kwargs to the output, and updates the associated tests to match.
2017-02-24 02:04:46 +00:00
if (kwargs_in) {
auto kwargs = reinterpret_borrow<dict>(kwargs_in);
if (kwargs.size() > 0) {
if (some_args) msg += "; ";
msg += "kwargs: ";
bool first = true;
for (auto kwarg : kwargs) {
if (first) first = false;
else msg += ", ";
msg += pybind11::str("{}={!r}").format(kwarg.first, kwarg.second);
}
}
}
Make TypeErrors more informative when an optional header is missing E.g. trying to convert a `list` to a `std::vector<int>` without including <pybind11/stl.h> will now raise an error with a note that suggests checking the headers. The note is only appended if `std::` is found in the function signature. This should only be the case when a header is missing. E.g. when stl.h is included, the signature would contain `List[int]` instead of `std::vector<int>` while using stl_bind.h would produce something like `MyVector`. Similarly for `std::map`/`Dict`, `complex`, `std::function`/`Callable`, etc. There's a possibility for false positives, but it's pretty low.
2017-09-09 18:21:34 +00:00
append_note_if_missing_header_is_suspected(msg);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
PyErr_SetString(PyExc_TypeError, msg.c_str());
return nullptr;
} else if (!result) {
std::string msg = "Unable to convert function return value to a "
"Python type! The signature was\n\t";
msg += it->signature;
Make TypeErrors more informative when an optional header is missing E.g. trying to convert a `list` to a `std::vector<int>` without including <pybind11/stl.h> will now raise an error with a note that suggests checking the headers. The note is only appended if `std::` is found in the function signature. This should only be the case when a header is missing. E.g. when stl.h is included, the signature would contain `List[int]` instead of `std::vector<int>` while using stl_bind.h would produce something like `MyVector`. Similarly for `std::map`/`Dict`, `complex`, `std::function`/`Callable`, etc. There's a possibility for false positives, but it's pretty low.
2017-09-09 18:21:34 +00:00
append_note_if_missing_header_is_suspected(msg);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
PyErr_SetString(PyExc_TypeError, msg.c_str());
return nullptr;
} else {
Reduce binary size overhead of new-style constructors The lookup of the `self` type and value pointer are moved out of template code and into `dispatcher`. This brings down the binary size of constructors back to the level of the old placement-new approach. (It also avoids a second lookup for `init_instance`.) With this implementation, mixing old- and new-style constructors in the same overload set may result in some runtime overhead for temporary allocations/deallocations, but this should be fine as old style constructors are phased out.
2017-08-17 00:01:32 +00:00
if (overloads->is_constructor && !self_value_and_holder.holder_constructed()) {
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
auto *pi = reinterpret_cast<instance *>(parent.ptr());
Reduce binary size overhead of new-style constructors The lookup of the `self` type and value pointer are moved out of template code and into `dispatcher`. This brings down the binary size of constructors back to the level of the old placement-new approach. (It also avoids a second lookup for `init_instance`.) With this implementation, mixing old- and new-style constructors in the same overload set may result in some runtime overhead for temporary allocations/deallocations, but this should be fine as old style constructors are phased out.
2017-08-17 00:01:32 +00:00
self_value_and_holder.type->init_instance(pi, nullptr);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
return result.ptr();
}
}
Initial commit
2015-07-05 18:05:44 +00:00
};
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/// Wrapper for Python extension modules
Initial commit
2015-07-05 18:05:44 +00:00
class module : public object {
public:
consistent macro naming throughout the project
2015-10-18 14:48:30 +00:00
PYBIND11_OBJECT_DEFAULT(module, object, PyModule_Check)
Initial commit
2015-07-05 18:05:44 +00:00
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/// Create a new top-level Python module with the given name and docstring
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
explicit module(const char *name, const char *doc = nullptr) {
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (!options::show_user_defined_docstrings()) doc = nullptr;
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
#if PY_MAJOR_VERSION >= 3
Initial commit
2015-07-05 18:05:44 +00:00
PyModuleDef *def = new PyModuleDef();
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
std::memset(def, 0, sizeof(PyModuleDef));
Initial commit
2015-07-05 18:05:44 +00:00
def->m_name = name;
def->m_doc = doc;
def->m_size = -1;
Py_INCREF(def);
m_ptr = PyModule_Create(def);
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
#else
m_ptr = Py_InitModule3(name, nullptr, doc);
#endif
Initial commit
2015-07-05 18:05:44 +00:00
if (m_ptr == nullptr)
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("Internal error in module::module()");
Initial commit
2015-07-05 18:05:44 +00:00
inc_ref();
}
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/** \rst
Create Python binding for a new function within the module scope. ``Func``
can be a plain C++ function, a function pointer, or a lambda function. For
details on the ``Extra&& ... extra`` argument, see section :ref:`extras`.
\endrst */
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename Func, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
module &def(const char *name_, Func &&f, const Extra& ... extra) {
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
cpp_function func(std::forward<Func>(f), name(name_), scope(*this),
sibling(getattr(*this, name_, none())), extra...);
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
// NB: allow overwriting here because cpp_function sets up a chain with the intention of
// overwriting (and has already checked internally that it isn't overwriting non-functions).
add_object(name_, func, true /* overwrite */);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/** \rst
Create and return a new Python submodule with the given name and docstring.
This also works recursively, i.e.
.. code-block:: cpp
py::module m("example", "pybind11 example plugin");
py::module m2 = m.def_submodule("sub", "A submodule of 'example'");
py::module m3 = m2.def_submodule("subsub", "A submodule of 'example.sub'");
\endrst */
more flexible function creation syntax
2015-07-11 15:41:48 +00:00
module def_submodule(const char *name, const char *doc = nullptr) {
Initial commit
2015-07-05 18:05:44 +00:00
std::string full_name = std::string(PyModule_GetName(m_ptr))
+ std::string(".") + std::string(name);
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
auto result = reinterpret_borrow<module>(PyImport_AddModule(full_name.c_str()));
Provide more control over automatic generation of docstrings (#486) Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
2016-11-15 11:38:05 +00:00
if (doc && options::show_user_defined_docstrings())
last breaking change: be consistent about the project name
2015-10-15 16:13:33 +00:00
result.attr("__doc__") = pybind11::str(doc);
Initial commit
2015-07-05 18:05:44 +00:00
attr(name) = result;
return result;
}
added module::import statement
2015-10-13 21:44:25 +00:00
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/// Import and return a module or throws `error_already_set`.
added module::import statement
2015-10-13 21:44:25 +00:00
static module import(const char *name) {
improved error handling at module import time
2015-12-26 13:04:52 +00:00
PyObject *obj = PyImport_ImportModule(name);
if (!obj)
print traceback on failed import (#537)
2016-12-01 10:35:34 +00:00
throw error_already_set();
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
return reinterpret_steal<module>(obj);
added module::import statement
2015-10-13 21:44:25 +00:00
}
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
Added function for reloading module (#1040)
2017-09-12 06:05:05 +00:00
/// Reload the module or throws `error_already_set`.
void reload() {
PyObject *obj = PyImport_ReloadModule(ptr());
if (!obj)
throw error_already_set();
*this = reinterpret_steal<module>(obj);
}
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
// Adds an object to the module using the given name. Throws if an object with the given name
// already exists.
//
// overwrite should almost always be false: attempting to overwrite objects that pybind11 has
// established will, in most cases, break things.
adjusted module::add_object signature so that it accepts a py::handle
2017-03-30 09:59:32 +00:00
PYBIND11_NOINLINE void add_object(const char *name, handle obj, bool overwrite = false) {
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
if (!overwrite && hasattr(*this, name))
pybind11_fail("Error during initialization: multiple incompatible definitions with name \"" +
std::string(name) + "\"");
adjusted module::add_object signature so that it accepts a py::handle
2017-03-30 09:59:32 +00:00
PyModule_AddObject(ptr(), name, obj.inc_ref().ptr() /* steals a reference */);
Prevent overwriting previous declarations Currently pybind11 doesn't check when you define a new object (e.g. a class, function, or exception) that overwrites an existing one. If the thing being overwritten is a class, this leads to a segfault (because pybind still thinks the type is defined, even though Python no longer has the type). In other cases this is harmless (e.g. replacing a function with an exception), but even in that case it's most likely a bug. This code doesn't prevent you from actively doing something harmful, like deliberately overwriting a previous definition, but detects overwriting with a run-time error if it occurs in the standard class/function/exception/def registration interfaces. All of the additions are in non-template code; the result is actually a tiny decrease in .so size compared to master without the new test code (977304 to 977272 bytes), and about 4K higher with the new tests.
2016-10-25 01:58:22 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
};
Add C++ interface for the Python interpreter
2017-03-29 22:20:42 +00:00
/// \ingroup python_builtins
Fix missing default globals in eval/exec when embedding Fixes #887.
2017-06-06 15:05:19 +00:00
/// Return a dictionary representing the global variables in the current execution frame,
/// or ``__main__.__dict__`` if there is no frame (usually when the interpreter is embedded).
inline dict globals() {
PyObject *p = PyEval_GetGlobals();
return reinterpret_borrow<dict>(p ? p : module::import("__main__").attr("__dict__").ptr());
}
Add C++ interface for the Python interpreter
2017-03-29 22:20:42 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
NAMESPACE_BEGIN(detail)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/// Generic support for creating new Python heap types
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
class generic_type : public object {
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
template <typename...> friend class class_;
Initial commit
2015-07-05 18:05:44 +00:00
public:
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
PYBIND11_OBJECT_DEFAULT(generic_type, object, PyType_Check)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
protected:
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
void initialize(const type_record &rec) {
if (rec.scope && hasattr(rec.scope, rec.name))
pybind11_fail("generic_type: cannot initialize type \"" + std::string(rec.name) +
"\": an object with that name is already defined");
don't allow registering a class twice (fixes #218)
2016-05-31 07:53:28 +00:00
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
if (rec.module_local ? get_local_type_info(*rec.type) : get_global_type_info(*rec.type))
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
pybind11_fail("generic_type: type \"" + std::string(rec.name) +
don't allow registering a class twice (fixes #218)
2016-05-31 07:53:28 +00:00
"\" is already registered!");
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
m_ptr = make_new_python_type(rec);
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
/* Register supplemental type information in C++ dict */
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
auto *tinfo = new detail::type_info();
tinfo->type = (PyTypeObject *) m_ptr;
Track base class pointers of instances This commits adds base class pointers of offset base classes (i.e. due to multiple inheritance) to `registered_instances` so that if such a pointer is returned we properly recognize it as an existing instance. Without this, returning a base class pointer will cast to the existing instance if the pointer happens to coincide with the instance pointer, but constructs a new instance (quite possibly with a segfault, if ownership is applied) for unequal base class pointers due to multiple inheritance.
2017-04-21 23:01:30 +00:00
tinfo->cpptype = rec.type;
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
tinfo->type_size = rec.type_size;
Support class-specific operator new and delete Fixes #754.
2017-03-21 00:15:20 +00:00
tinfo->operator_new = rec.operator_new;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
tinfo->holder_size_in_ptrs = size_in_ptrs(rec.holder_size);
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
tinfo->init_instance = rec.init_instance;
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
tinfo->dealloc = rec.dealloc;
Track base class pointers of instances This commits adds base class pointers of offset base classes (i.e. due to multiple inheritance) to `registered_instances` so that if such a pointer is returned we properly recognize it as an existing instance. Without this, returning a base class pointer will cast to the existing instance if the pointer happens to coincide with the instance pointer, but constructs a new instance (quite possibly with a segfault, if ownership is applied) for unequal base class pointers due to multiple inheritance.
2017-04-21 23:01:30 +00:00
tinfo->simple_type = true;
tinfo->simple_ancestors = true;
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
tinfo->default_holder = rec.default_holder;
tinfo->module_local = rec.module_local;
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
auto &internals = get_internals();
auto tindex = std::type_index(*rec.type);
Require existing typeinfo for direct conversions This avoid a hashmap lookup since the pointer to the list of direct converters is now cached in the typeinfo.
2016-10-23 14:27:13 +00:00
tinfo->direct_conversions = &internals.direct_conversions[tindex];
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
if (rec.module_local)
registered_local_types_cpp()[tindex] = tinfo;
else
internals.registered_types_cpp[tindex] = tinfo;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
internals.registered_types_py[(PyTypeObject *) m_ptr] = { tinfo };
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
Track base class pointers of instances This commits adds base class pointers of offset base classes (i.e. due to multiple inheritance) to `registered_instances` so that if such a pointer is returned we properly recognize it as an existing instance. Without this, returning a base class pointer will cast to the existing instance if the pointer happens to coincide with the instance pointer, but constructs a new instance (quite possibly with a segfault, if ownership is applied) for unequal base class pointers due to multiple inheritance.
2017-04-21 23:01:30 +00:00
if (rec.bases.size() > 1 || rec.multiple_inheritance) {
Make all classes with the same instance size derive from a common base In order to fully satisfy Python's inheritance type layout requirements, all types should have a common 'solid' base. A solid base is one which has the same instance size as the derived type (not counting the space required for the optional `dict_ptr` and `weakrefs_ptr`). Thus, `object` does not qualify as a solid base for pybind11 types and this can lead to issues with multiple inheritance. To get around this, new base types are created: one per unique instance size. There is going to be very few of these bases. They ensure Python's MRO checks will pass when multiple bases are involved.
2017-02-15 20:10:25 +00:00
mark_parents_nonsimple(tinfo->type);
Track base class pointers of instances This commits adds base class pointers of offset base classes (i.e. due to multiple inheritance) to `registered_instances` so that if such a pointer is returned we properly recognize it as an existing instance. Without this, returning a base class pointer will cast to the existing instance if the pointer happens to coincide with the instance pointer, but constructs a new instance (quite possibly with a segfault, if ownership is applied) for unequal base class pointers due to multiple inheritance.
2017-04-21 23:01:30 +00:00
tinfo->simple_ancestors = false;
}
else if (rec.bases.size() == 1) {
auto parent_tinfo = get_type_info((PyTypeObject *) rec.bases[0].ptr());
tinfo->simple_ancestors = parent_tinfo->simple_ancestors;
}
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
if (rec.module_local) {
// Stash the local typeinfo and loader so that external modules can access it.
tinfo->module_local_load = &type_caster_generic::local_load;
Change internals ID and versioning scheme to avoid module conflicts The current PYBIND11_INTERNALS_ID depends on the version of the library in order to isolate binary incompatible internals capsules. However, this does not preclude conflicts between modules built from different (binary incompatible) commits with the same version number. For example, if one module was built with an early v2.2.dev and submitted to PyPI, it could not be loaded alongside a v2.2.x release module -- it would segfault because of incompatible internals with the same ID. This PR changes the ID to depend on PYBIND11_INTERNALS_VERSION which is independent of the main library version. It's an integer which should be incremented whenever a binary incompatible change is made to internals. PYBIND11_INTERNALS_KIND is also introduced for a similar reason. The same versioning scheme is also applied to `type_info` and the `module_local` type attribute.
2017-08-20 15:14:09 +00:00
setattr(m_ptr, PYBIND11_MODULE_LOCAL_ID, capsule(tinfo));
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
}
Multiple inheritance support
2016-09-11 11:00:40 +00:00
/// Helper function which tags all parents of a type using mult. inheritance
void mark_parents_nonsimple(PyTypeObject *value) {
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
auto t = reinterpret_borrow<tuple>(value->tp_bases);
Multiple inheritance support
2016-09-11 11:00:40 +00:00
for (handle h : t) {
auto tinfo2 = get_type_info((PyTypeObject *) h.ptr());
if (tinfo2)
tinfo2->simple_type = false;
mark_parents_nonsimple((PyTypeObject *) h.ptr());
}
}
complex number support
2015-07-28 14:12:20 +00:00
void install_buffer_funcs(
buffer_info *(*get_buffer)(PyObject *, void *),
void *get_buffer_data) {
Initial commit
2015-07-05 18:05:44 +00:00
PyHeapTypeObject *type = (PyHeapTypeObject*) m_ptr;
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
auto tinfo = detail::get_type_info(&type->ht_type);
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
if (!type->ht_type.tp_as_buffer)
pybind11_fail(
"To be able to register buffer protocol support for the type '" +
std::string(tinfo->type->tp_name) +
"' the associated class<>(..) invocation must "
"include the pybind11::buffer_protocol() annotation!");
fully moved __pybind11__ Python attributes to the C++ side, cleanup & documentation pass over the main header file
2016-01-17 21:36:41 +00:00
tinfo->get_buffer = get_buffer;
tinfo->get_buffer_data = get_buffer_data;
Initial commit
2015-07-05 18:05:44 +00:00
}
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
// rec_func must be set for either fget or fset.
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
void def_property_static_impl(const char *name,
handle fget, handle fset,
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
detail::function_record *rec_func) {
const auto is_static = rec_func && !(rec_func->is_method && rec_func->scope);
const auto has_doc = rec_func && rec_func->doc && pybind11::options::show_user_defined_docstrings();
Reimplement static properties by extending PyProperty_Type Instead of creating a new unique metaclass for each type, the builtin `property` type is subclassed to support static properties. The new setter/getters always pass types instead of instances in their `self` argument. A metaclass is still required to support this behavior, but it doesn't store any data anymore, so a new one doesn't need to be created for each class. There is now only one common metaclass which is shared by all pybind11 types.
2017-02-13 17:11:24 +00:00
auto property = handle((PyObject *) (is_static ? get_internals().static_property_type
: &PyProperty_Type));
attr(name) = property(fget.ptr() ? fget : none(),
fset.ptr() ? fset : none(),
/*deleter*/none(),
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
pybind11::str(has_doc ? rec_func->doc : ""));
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
};
Allow passing base types as a template parameter This allows a slightly cleaner base type specification of: py::class_<Type, Base>("Type") as an alternative to py::class_<Type>("Type", py::base<Base>()) As with the other template parameters, the order relative to the holder or trampoline types doesn't matter. This also includes a compile-time assertion failure if attempting to specify more than one base class (but is easily extendible to support multiple inheritance, someday, by updating the class_selector::set_bases function to set multiple bases).
2016-09-06 16:27:00 +00:00
Support class-specific operator new and delete Fixes #754.
2017-03-21 00:15:20 +00:00
/// Set the pointer to operator new if it exists. The cast is needed because it can be overloaded.
template <typename T, typename = void_t<decltype(static_cast<void *(*)(size_t)>(T::operator new))>>
void set_operator_new(type_record *r) { r->operator_new = &T::operator new; }
template <typename> void set_operator_new(...) { }
Add support custom sized operator deletes (#952) If a class doesn't provide a `T::operator delete(void *)` but does have a `T::operator delete(void *, size_t)` the latter is invoked by a `delete someT`. Pybind currently only look for and call the former; this commit adds detection and calling of the latter when the former doesn't exist.
2017-07-23 04:32:58 +00:00
template <typename T, typename SFINAE = void> struct has_operator_delete : std::false_type { };
template <typename T> struct has_operator_delete<T, void_t<decltype(static_cast<void (*)(void *)>(T::operator delete))>>
: std::true_type { };
template <typename T, typename SFINAE = void> struct has_operator_delete_size : std::false_type { };
template <typename T> struct has_operator_delete_size<T, void_t<decltype(static_cast<void (*)(void *, size_t)>(T::operator delete))>>
: std::true_type { };
Support class-specific operator new and delete Fixes #754.
2017-03-21 00:15:20 +00:00
/// Call class-specific delete if it exists or global otherwise. Can also be an overload set.
Add support custom sized operator deletes (#952) If a class doesn't provide a `T::operator delete(void *)` but does have a `T::operator delete(void *, size_t)` the latter is invoked by a `delete someT`. Pybind currently only look for and call the former; this commit adds detection and calling of the latter when the former doesn't exist.
2017-07-23 04:32:58 +00:00
template <typename T, enable_if_t<has_operator_delete<T>::value, int> = 0>
void call_operator_delete(T *p, size_t) { T::operator delete(p); }
template <typename T, enable_if_t<!has_operator_delete<T>::value && has_operator_delete_size<T>::value, int> = 0>
void call_operator_delete(T *p, size_t s) { T::operator delete(p, s); }
Support class-specific operator new and delete Fixes #754.
2017-03-21 00:15:20 +00:00
Add support custom sized operator deletes (#952) If a class doesn't provide a `T::operator delete(void *)` but does have a `T::operator delete(void *, size_t)` the latter is invoked by a `delete someT`. Pybind currently only look for and call the former; this commit adds detection and calling of the latter when the former doesn't exist.
2017-07-23 04:32:58 +00:00
inline void call_operator_delete(void *p, size_t) { ::operator delete(p); }
Support class-specific operator new and delete Fixes #754.
2017-03-21 00:15:20 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
NAMESPACE_END(detail)
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
/// Given a pointer to a member function, cast it to its `Derived` version.
/// Forward everything else unchanged.
template <typename /*Derived*/, typename F>
auto method_adaptor(F &&f) -> decltype(std::forward<F>(f)) { return std::forward<F>(f); }
template <typename Derived, typename Return, typename Class, typename... Args>
Add informative compilation failure for method_adaptor failures When using `method_adaptor` (usually implicitly via a `cl.def("f", &D::f)`) a compilation failure results if `f` is actually a method of an inaccessible base class made public via `using`, such as: class B { public: void f() {} }; class D : private B { public: using B::f; }; pybind deduces `&D::f` as a `B` member function pointer. Since the base class is inaccessible, the cast in `method_adaptor` from a base class member function pointer to derived class member function pointer isn't valid, and a cast failure results. This was sort of a regression in 2.2, which introduced `method_adaptor` to do the expected thing when the base class *is* accessible. It wasn't actually something that *worked* in 2.1, though: you wouldn't get a compile-time failure, but the method was not callable (because the `D *` couldn't be cast to a `B *` because of the access restriction). As a result, you'd simply get a run-time failure if you ever tried to call the function (this is what #855 fixed). Thus the change in 2.2 essentially promoted a run-time failure to a compile-time failure, so isn't really a regression. This commit simply adds a `static_assert` with an accessible-base-class check so that, rather than just a cryptic cast failure, you get something more informative (along with a suggestion for a workaround). The workaround is to use a lambda, e.g.: class Derived : private Base { public: using Base::f; }; // In binding code: //cl.def("f", &Derived::f); // fails: &Derived::f is actually a base // class member function pointer cl.def("f", [](Derived &self) { return self.f(); }); This is a bit of a nuissance (especially if there are a bunch of arguments to forward), but I don't really see another solution. Fixes #1124
2017-10-03 13:09:49 +00:00
auto method_adaptor(Return (Class::*pmf)(Args...)) -> Return (Derived::*)(Args...) {
static_assert(detail::is_accessible_base_of<Class, Derived>::value,
"Cannot bind an inaccessible base class method; use a lambda definition instead");
return pmf;
}
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
template <typename Derived, typename Return, typename Class, typename... Args>
Add informative compilation failure for method_adaptor failures When using `method_adaptor` (usually implicitly via a `cl.def("f", &D::f)`) a compilation failure results if `f` is actually a method of an inaccessible base class made public via `using`, such as: class B { public: void f() {} }; class D : private B { public: using B::f; }; pybind deduces `&D::f` as a `B` member function pointer. Since the base class is inaccessible, the cast in `method_adaptor` from a base class member function pointer to derived class member function pointer isn't valid, and a cast failure results. This was sort of a regression in 2.2, which introduced `method_adaptor` to do the expected thing when the base class *is* accessible. It wasn't actually something that *worked* in 2.1, though: you wouldn't get a compile-time failure, but the method was not callable (because the `D *` couldn't be cast to a `B *` because of the access restriction). As a result, you'd simply get a run-time failure if you ever tried to call the function (this is what #855 fixed). Thus the change in 2.2 essentially promoted a run-time failure to a compile-time failure, so isn't really a regression. This commit simply adds a `static_assert` with an accessible-base-class check so that, rather than just a cryptic cast failure, you get something more informative (along with a suggestion for a workaround). The workaround is to use a lambda, e.g.: class Derived : private Base { public: using Base::f; }; // In binding code: //cl.def("f", &Derived::f); // fails: &Derived::f is actually a base // class member function pointer cl.def("f", [](Derived &self) { return self.f(); }); This is a bit of a nuissance (especially if there are a bunch of arguments to forward), but I don't really see another solution. Fixes #1124
2017-10-03 13:09:49 +00:00
auto method_adaptor(Return (Class::*pmf)(Args...) const) -> Return (Derived::*)(Args...) const {
static_assert(detail::is_accessible_base_of<Class, Derived>::value,
"Cannot bind an inaccessible base class method; use a lambda definition instead");
return pmf;
}
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
template <typename type_, typename... options>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class class_ : public detail::generic_type {
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
template <typename T> using is_holder = detail::is_holder_type<type_, T>;
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
template <typename T> using is_subtype = detail::is_strict_base_of<type_, T>;
template <typename T> using is_base = detail::is_strict_base_of<T, type_>;
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
// struct instead of using here to help MSVC:
template <typename T> struct is_valid_class_option :
detail::any_of<is_holder<T>, is_subtype<T>, is_base<T>> {};
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
public:
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
using type = type_;
Replace first_of_t with exactly_one_t
2017-03-29 09:55:18 +00:00
using type_alias = detail::exactly_one_t<is_subtype, void, options...>;
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
constexpr static bool has_alias = !std::is_void<type_alias>::value;
Replace first_of_t with exactly_one_t
2017-03-29 09:55:18 +00:00
using holder_type = detail::exactly_one_t<is_holder, std::unique_ptr<type>, options...>;
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
static_assert(detail::all_of<is_valid_class_option<options>...>::value,
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
"Unknown/invalid class_ template parameters provided");
Initial commit
2015-07-05 18:05:44 +00:00
Add a polymorphic static assert when using an alias An alias can be used for two main purposes: to override virtual methods, and to add some extra data to a class needed for the pybind-wrapper. Both of these absolutely require that the wrapped class be polymorphic so that virtual dispatch and destruction, respectively, works.
2017-06-13 01:48:36 +00:00
static_assert(!has_alias || std::is_polymorphic<type>::value,
"Cannot use an alias class with a non-polymorphic type");
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
PYBIND11_OBJECT(class_, generic_type, PyType_Check)
Initial commit
2015-07-05 18:05:44 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
template <typename... Extra>
class_(handle scope, const char *name, const Extra &... extra) {
Fail to compile with MI via class_ ctor parameters We can't support this for classes from imported modules (which is the primary purpose of a ctor argument base class) because we *have* to have both parent and derived to properly extract a multiple-inheritance base class pointer from a derived class pointer. We could support this for actual `class_<Base, ...> instances, but since in that case the `Base` is already present in the code, it seems more consistent to simply always require MI to go via template options.
2017-03-16 23:10:48 +00:00
using namespace detail;
// MI can only be specified via class_ template options, not constructor parameters
static_assert(
none_of<is_pyobject<Extra>...>::value || // no base class arguments, or:
( constexpr_sum(is_pyobject<Extra>::value...) == 1 && // Exactly one base
constexpr_sum(is_base<options>::value...) == 0 && // no template option bases
none_of<std::is_same<multiple_inheritance, Extra>...>::value), // no multiple_inheritance attr
"Error: multiple inheritance bases must be specified via class_ template options");
type_record record;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
record.scope = scope;
record.name = name;
record.type = &typeid(type);
Fail to compile with MI via class_ ctor parameters We can't support this for classes from imported modules (which is the primary purpose of a ctor argument base class) because we *have* to have both parent and derived to properly extract a multiple-inheritance base class pointer from a derived class pointer. We could support this for actual `class_<Base, ...> instances, but since in that case the `Base` is already present in the code, it seems more consistent to simply always require MI to go via template options.
2017-03-16 23:10:48 +00:00
record.type_size = sizeof(conditional_t<has_alias, type_alias, type>);
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
record.holder_size = sizeof(holder_type);
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
record.init_instance = init_instance;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
record.dealloc = dealloc;
Add check for matching holder_type when inheriting (#588)
2017-01-31 15:52:11 +00:00
record.default_holder = std::is_same<holder_type, std::unique_ptr<type>>::value;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Support class-specific operator new and delete Fixes #754.
2017-03-21 00:15:20 +00:00
set_operator_new<type>(&record);
Multiple inheritance support
2016-09-11 11:00:40 +00:00
/* Register base classes specified via template arguments to class_, if any */
Add PYBIND11_EXPAND_SIDE_EFFECTS macro This allows calling of functions (typically void) over a parameter pack, replacing usage such as: bool unused[] = { (voidfunc(param_pack_arg), false)..., false }; (void) unused; with a much cleaner: PYBIND11_EXPAND_SIDE_EFFECTS(voidfunc(param_pack_arg));
2017-03-26 01:41:06 +00:00
PYBIND11_EXPAND_SIDE_EFFECTS(add_base<options>(record));
Allow passing base types as a template parameter This allows a slightly cleaner base type specification of: py::class_<Type, Base>("Type") as an alternative to py::class_<Type>("Type", py::base<Base>()) As with the other template parameters, the order relative to the holder or trampoline types doesn't matter. This also includes a compile-time assertion failure if attempting to specify more than one base class (but is easily extendible to support multiple inheritance, someday, by updating the class_selector::set_bases function to set multiple bases).
2016-09-06 16:27:00 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
/* Process optional arguments, if any */
Fail to compile with MI via class_ ctor parameters We can't support this for classes from imported modules (which is the primary purpose of a ctor argument base class) because we *have* to have both parent and derived to properly extract a multiple-inheritance base class pointer from a derived class pointer. We could support this for actual `class_<Base, ...> instances, but since in that case the `Base` is already present in the code, it seems more consistent to simply always require MI to go via template options.
2017-03-16 23:10:48 +00:00
process_attributes<Extra...>::init(extra..., &record);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Fail to compile with MI via class_ ctor parameters We can't support this for classes from imported modules (which is the primary purpose of a ctor argument base class) because we *have* to have both parent and derived to properly extract a multiple-inheritance base class pointer from a derived class pointer. We could support this for actual `class_<Base, ...> instances, but since in that case the `Base` is already present in the code, it seems more consistent to simply always require MI to go via template options.
2017-03-16 23:10:48 +00:00
generic_type::initialize(record);
Redesigned virtual call mechanism and user-facing syntax (breaking change!) Sergey Lyskov pointed out that the trampoline mechanism used to override virtual methods from within Python caused unnecessary overheads when instantiating the original (i.e. non-extended) class. This commit removes this inefficiency, but some syntax changes were needed to achieve this. Projects using this features will need to make a few changes: In particular, the example below shows the old syntax to instantiate a class with a trampoline: class_<TrampolineClass>("MyClass") .alias<MyClass>() .... This is what should be used now: class_<MyClass, std::unique_ptr<MyClass, TrampolineClass>("MyClass") .... Importantly, the trampoline class is now specified as the *third* argument to the class_ template, and the alias<..>() call is gone. The second argument with the unique pointer is simply the default holder type used by pybind11.
2016-05-26 11:19:27 +00:00
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
if (has_alias) {
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
auto &instances = record.module_local ? registered_local_types_cpp() : get_internals().registered_types_cpp;
Redesigned virtual call mechanism and user-facing syntax (breaking change!) Sergey Lyskov pointed out that the trampoline mechanism used to override virtual methods from within Python caused unnecessary overheads when instantiating the original (i.e. non-extended) class. This commit removes this inefficiency, but some syntax changes were needed to achieve this. Projects using this features will need to make a few changes: In particular, the example below shows the old syntax to instantiate a class with a trampoline: class_<TrampolineClass>("MyClass") .alias<MyClass>() .... This is what should be used now: class_<MyClass, std::unique_ptr<MyClass, TrampolineClass>("MyClass") .... Importantly, the trampoline class is now specified as the *third* argument to the class_ template, and the alias<..>() call is gone. The second argument with the unique pointer is simply the default holder type used by pybind11.
2016-05-26 11:19:27 +00:00
instances[std::type_index(typeid(type_alias))] = instances[std::type_index(typeid(type))];
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
use detail::enable_if_t everywhere
2016-09-12 15:36:43 +00:00
template <typename Base, detail::enable_if_t<is_base<Base>::value, int> = 0>
Multiple inheritance support
2016-09-11 11:00:40 +00:00
static void add_base(detail::type_record &rec) {
Use std::type_info::name() for type lookups outside stdlibc++ Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes #912.
2017-06-21 17:38:10 +00:00
rec.add_base(typeid(Base), [](void *src) -> void * {
Multiple inheritance support
2016-09-11 11:00:40 +00:00
return static_cast<Base *>(reinterpret_cast<type *>(src));
});
}
use detail::enable_if_t everywhere
2016-09-12 15:36:43 +00:00
template <typename Base, detail::enable_if_t<!is_base<Base>::value, int> = 0>
Multiple inheritance support
2016-09-11 11:00:40 +00:00
static void add_base(detail::type_record &) { }
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename Func, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ &def(const char *name_, Func&& f, const Extra&... extra) {
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
cpp_function cf(method_adaptor<type>(std::forward<Func>(f)), name(name_), is_method(*this),
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
sibling(getattr(*this, name_, none())), extra...);
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
attr(cf.name()) = cf;
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename Func, typename... Extra> class_ &
Add static_assert failure for non-static def_static Fixes #697
2017-03-12 20:59:07 +00:00
def_static(const char *name_, Func &&f, const Extra&... extra) {
static_assert(!std::is_member_function_pointer<Func>::value,
"def_static(...) called with a non-static member function pointer");
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
cpp_function cf(std::forward<Func>(f), name(name_), scope(*this),
sibling(getattr(*this, name_, none())), extra...);
support for ancient Python versions (2.7.x)
2015-09-04 21:42:12 +00:00
attr(cf.name()) = cf;
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <detail::op_id id, detail::op_type ot, typename L, typename R, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ &def(const detail::op_<id, ot, L, R> &op, const Extra&... extra) {
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
op.execute(*this, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <detail::op_id id, detail::op_type ot, typename L, typename R, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ & def_cast(const detail::op_<id, ot, L, R> &op, const Extra&... extra) {
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
op.execute_cast(*this, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename... Args, typename... Extra>
Reimplement py::init<...> to use common factory code This reimplements the py::init<...> implementations using the various functions added to support `py::init(...)`, and moves the implementing structs into `detail/init.h` from `pybind11.h`. It doesn't simply use a factory directly, as this is a very common case and implementation without an extra lambda call is a small but useful optimization. This, combined with the previous lazy initialization, also avoids needing placement new for `py::init<...>()` construction: such construction now occurs via an ordinary `new Type(...)`. A consequence of this is that it also fixes a potential bug when using multiple inheritance from Python: it was very easy to write classes that double-initialize an existing instance which had the potential to leak for non-pod classes. With the new implementation, an attempt to call `__init__` on an already-initialized object is now ignored. (This was already done in the previous commit for factory constructors). This change exposed a few warnings (fixed here) from deleting a pointer to a base class with virtual functions but without a virtual destructor. These look like legitimate warnings that we shouldn't suppress; this adds virtual destructors to the appropriate classes.
2017-08-17 04:01:42 +00:00
class_ &def(const detail::initimpl::constructor<Args...> &init, const Extra&... extra) {
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
init.execute(*this, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
Redesigned virtual call mechanism and user-facing syntax (breaking change!) Sergey Lyskov pointed out that the trampoline mechanism used to override virtual methods from within Python caused unnecessary overheads when instantiating the original (i.e. non-extended) class. This commit removes this inefficiency, but some syntax changes were needed to achieve this. Projects using this features will need to make a few changes: In particular, the example below shows the old syntax to instantiate a class with a trampoline: class_<TrampolineClass>("MyClass") .alias<MyClass>() .... This is what should be used now: class_<MyClass, std::unique_ptr<MyClass, TrampolineClass>("MyClass") .... Importantly, the trampoline class is now specified as the *third* argument to the class_ template, and the alias<..>() call is gone. The second argument with the unique pointer is simply the default holder type used by pybind11.
2016-05-26 11:19:27 +00:00
template <typename... Args, typename... Extra>
Reimplement py::init<...> to use common factory code This reimplements the py::init<...> implementations using the various functions added to support `py::init(...)`, and moves the implementing structs into `detail/init.h` from `pybind11.h`. It doesn't simply use a factory directly, as this is a very common case and implementation without an extra lambda call is a small but useful optimization. This, combined with the previous lazy initialization, also avoids needing placement new for `py::init<...>()` construction: such construction now occurs via an ordinary `new Type(...)`. A consequence of this is that it also fixes a potential bug when using multiple inheritance from Python: it was very easy to write classes that double-initialize an existing instance which had the potential to leak for non-pod classes. With the new implementation, an attempt to call `__init__` on an already-initialized object is now ignored. (This was already done in the previous commit for factory constructors). This change exposed a few warnings (fixed here) from deleting a pointer to a base class with virtual functions but without a virtual destructor. These look like legitimate warnings that we shouldn't suppress; this adds virtual destructors to the appropriate classes.
2017-08-17 04:01:42 +00:00
class_ &def(const detail::initimpl::alias_constructor<Args...> &init, const Extra&... extra) {
Allow arbitrary class_ template option ordering The current pybind11::class_<Type, Holder, Trampoline> fixed template ordering results in a requirement to repeat the Holder with its default value (std::unique_ptr<Type>) argument, which is a little bit annoying: it needs to be specified not because we want to override the default, but rather because we need to specify the third argument. This commit removes this limitation by making the class_ template take the type name plus a parameter pack of options. It then extracts the first valid holder type and the first subclass type for holder_type and trampoline type_alias, respectively. (If unfound, both fall back to their current defaults, `std::unique_ptr<type>` and `type`, respectively). If any unmatched template arguments are provided, a static assertion fails. What this means is that you can specify or omit the arguments in any order: py::class_<A, PyA> c1(m, "A"); py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B"); py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C"); It also allows future class attributes (such as base types in the next commit) to be passed as class template types rather than needing to use a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
init.execute(*this, extra...);
Redesigned virtual call mechanism and user-facing syntax (breaking change!) Sergey Lyskov pointed out that the trampoline mechanism used to override virtual methods from within Python caused unnecessary overheads when instantiating the original (i.e. non-extended) class. This commit removes this inefficiency, but some syntax changes were needed to achieve this. Projects using this features will need to make a few changes: In particular, the example below shows the old syntax to instantiate a class with a trampoline: class_<TrampolineClass>("MyClass") .alias<MyClass>() .... This is what should be used now: class_<MyClass, std::unique_ptr<MyClass, TrampolineClass>("MyClass") .... Importantly, the trampoline class is now specified as the *third* argument to the class_ template, and the alias<..>() call is gone. The second argument with the unique pointer is simply the default holder type used by pybind11.
2016-05-26 11:19:27 +00:00
return *this;
}
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
template <typename... Args, typename... Extra>
class_ &def(detail::initimpl::factory<Args...> &&init, const Extra&... extra) {
std::move(init).execute(*this, extra...);
return *this;
}
Add py::pickle() adaptor for safer __getstate__/__setstate__ bindings This is analogous to `py::init()` vs `__init__` + placement-new. `py::pickle()` reuses most of the implementation details of `py::init()`.
2017-08-23 23:53:15 +00:00
template <typename... Args, typename... Extra>
class_ &def(detail::initimpl::pickle_factory<Args...> &&pf, const Extra &...extra) {
std::move(pf).execute(*this, extra...);
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename Func> class_& def_buffer(Func &&func) {
complex number support
2015-07-28 14:12:20 +00:00
struct capture { Func func; };
capture *ptr = new capture { std::forward<Func>(func) };
install_buffer_funcs([](PyObject *obj, void *ptr) -> buffer_info* {
Fix pointer to reference error in type_caster on MSVC (#583)
2017-01-03 10:52:05 +00:00
detail::make_caster<type> caster;
Initial commit
2015-07-05 18:05:44 +00:00
if (!caster.load(obj, false))
return nullptr;
complex number support
2015-07-28 14:12:20 +00:00
return new buffer_info(((capture *) ptr)->func(caster));
}, ptr);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
Support pointers to member functions in def_buffer. Closes #857, by adding overloads to def_buffer that match pointers to member functions and wrap them in lambdas.
2017-05-17 08:52:33 +00:00
template <typename Return, typename Class, typename... Args>
class_ &def_buffer(Return (Class::*func)(Args...)) {
return def_buffer([func] (type &obj) { return (obj.*func)(); });
}
template <typename Return, typename Class, typename... Args>
class_ &def_buffer(Return (Class::*func)(Args...) const) {
return def_buffer([func] (const type &obj) { return (obj.*func)(); });
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename C, typename D, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ &def_readwrite(const char *name, D C::*pm, const Extra&... extra) {
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
static_assert(std::is_base_of<C, type>::value, "def_readwrite() requires a class member (or base class member)");
cpp_function fget([pm](const type &c) -> const D &{ return c.*pm; }, is_method(*this)),
fset([pm](type &c, const D &value) { c.*pm = value; }, is_method(*this));
improve default parameters for properties
2016-03-25 15:13:10 +00:00
def_property(name, fget, fset, return_value_policy::reference_internal, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename C, typename D, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ &def_readonly(const char *name, const D C::*pm, const Extra& ...extra) {
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
static_assert(std::is_base_of<C, type>::value, "def_readonly() requires a class member (or base class member)");
cpp_function fget([pm](const type &c) -> const D &{ return c.*pm; }, is_method(*this));
improve default parameters for properties
2016-03-25 15:13:10 +00:00
def_property_readonly(name, fget, return_value_policy::reference_internal, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename D, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ &def_readwrite_static(const char *name, D *pm, const Extra& ...extra) {
improve default parameters for properties
2016-03-25 15:13:10 +00:00
cpp_function fget([pm](object) -> const D &{ return *pm; }, scope(*this)),
fset([pm](object, const D &value) { *pm = value; }, scope(*this));
def_property_static(name, fget, fset, return_value_policy::reference, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
switched cpp_function to use variadic arguments
2015-07-29 15:43:52 +00:00
template <typename D, typename... Extra>
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class_ &def_readonly_static(const char *name, const D *pm, const Extra& ...extra) {
improve default parameters for properties
2016-03-25 15:13:10 +00:00
cpp_function fget([pm](object) -> const D &{ return *pm; }, scope(*this));
def_property_readonly_static(name, fget, return_value_policy::reference, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
/// Uses return_value_policy::reference_internal by default
template <typename Getter, typename... Extra>
class_ &def_property_readonly(const char *name, const Getter &fget, const Extra& ...extra) {
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
return def_property_readonly(name, cpp_function(method_adaptor<type>(fget)),
return_value_policy::reference_internal, extra...);
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
}
/// Uses cpp_function's return_value_policy by default
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
template <typename... Extra>
class_ &def_property_readonly(const char *name, const cpp_function &fget, const Extra& ...extra) {
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
return def_property(name, fget, nullptr, extra...);
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
}
/// Uses return_value_policy::reference by default
template <typename Getter, typename... Extra>
class_ &def_property_readonly_static(const char *name, const Getter &fget, const Extra& ...extra) {
return def_property_readonly_static(name, cpp_function(fget), return_value_policy::reference, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
}
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
/// Uses cpp_function's return_value_policy by default
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
template <typename... Extra>
class_ &def_property_readonly_static(const char *name, const cpp_function &fget, const Extra& ...extra) {
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
return def_property_static(name, fget, nullptr, extra...);
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
}
/// Uses return_value_policy::reference_internal by default
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
template <typename Getter, typename Setter, typename... Extra>
class_ &def_property(const char *name, const Getter &fget, const Setter &fset, const Extra& ...extra) {
return def_property(name, fget, cpp_function(method_adaptor<type>(fset)), extra...);
}
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
template <typename Getter, typename... Extra>
class_ &def_property(const char *name, const Getter &fget, const cpp_function &fset, const Extra& ...extra) {
Override deduced Base class when defining Derived methods When defining method from a member function pointer (e.g. `.def("f", &Derived::f)`) we run into a problem if `&Derived::f` is actually implemented in some base class `Base` when `Base` isn't pybind-registered. This happens because the class type is deduced from the member function pointer, which then becomes a lambda with first argument this deduced type. For a base class implementation, the deduced type is `Base`, not `Derived`, and so we generate and registered an overload which takes a `Base *` as first argument. Trying to call this fails if `Base` isn't registered (e.g. because it's an implementation detail class that isn't intended to be exposed to Python) because the type caster for an unregistered type always fails. This commit adds a `method_adaptor` function that rebinds a member function to a derived type member function and otherwise (i.e. regular functions/lambda) leaves the argument as-is. This is now used for class definitions so that they are bound with type being registered rather than a potential base type. A closely related fix in this commit is to similarly update the lambdas used for `def_readwrite` (and related) to bind to the class type being registered rather than the deduced type so that registering a property that resolves to a base class member similarly generates a usable function. Fixes #854, #910. Co-Authored-By: Dean Moldovan <dean0x7d@gmail.com>
2017-05-16 15:07:28 +00:00
return def_property(name, cpp_function(method_adaptor<type>(fget)), fset,
return_value_policy::reference_internal, extra...);
Initial commit
2015-07-05 18:05:44 +00:00
}
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
/// Uses cpp_function's return_value_policy by default
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
template <typename... Extra>
class_ &def_property(const char *name, const cpp_function &fget, const cpp_function &fset, const Extra& ...extra) {
improve default parameters for properties
2016-03-25 15:13:10 +00:00
return def_property_static(name, fget, fset, is_method(*this), extra...);
Initial commit
2015-07-05 18:05:44 +00:00
}
Make reference(_internal) the default return value policy for properties (#473) * Make reference(_internal) the default return value policy for properties Before this, all `def_property*` functions used `automatic` as their default return value policy. This commit makes it so that: * Non-static properties use `reference_interal` by default, thus matching `def_readonly` and `def_readwrite`. * Static properties use `reference` by default, thus matching `def_readonly_static` and `def_readwrite_static`. In case `cpp_function` is passed to any `def_property*`, its policy will be used instead of any defaults. User-defined arguments in `extras` still have top priority and will override both the default policies and the ones from `cpp_function`. Resolves #436. * Almost always use return_value_policy::move for rvalues For functions which return rvalues or rvalue references, the only viable return value policies are `copy` and `move`. `reference(_internal)` and `take_ownership` would take the address of a temporary which is always an error. This commit prevents possible user errors by overriding the bad rvalue policies with `move`. Besides `move`, only `copy` is allowed, and only if it's explicitly selected by the user. This is also a necessary safety feature to support the new default return value policies for properties: `reference(_internal)`.
2016-11-01 10:44:57 +00:00
/// Uses return_value_policy::reference by default
template <typename Getter, typename... Extra>
class_ &def_property_static(const char *name, const Getter &fget, const cpp_function &fset, const Extra& ...extra) {
return def_property_static(name, cpp_function(fget), fset, return_value_policy::reference, extra...);
}
/// Uses cpp_function's return_value_policy by default
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
template <typename... Extra>
class_ &def_property_static(const char *name, const cpp_function &fget, const cpp_function &fset, const Extra& ...extra) {
auto rec_fget = get_function_record(fget), rec_fset = get_function_record(fset);
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
auto *rec_active = rec_fget;
if (rec_fget) {
char *doc_prev = rec_fget->doc; /* 'extra' field may include a property-specific documentation string */
detail::process_attributes<Extra...>::init(extra..., rec_fget);
if (rec_fget->doc && rec_fget->doc != doc_prev) {
free(doc_prev);
rec_fget->doc = strdup(rec_fget->doc);
}
fix segfault when passing a docstring to def_property* (fixes #222)
2016-06-02 18:33:01 +00:00
}
if (rec_fset) {
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
char *doc_prev = rec_fset->doc;
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
detail::process_attributes<Extra...>::init(extra..., rec_fset);
fix segfault when passing a docstring to def_property* (fixes #222)
2016-06-02 18:33:01 +00:00
if (rec_fset->doc && rec_fset->doc != doc_prev) {
free(doc_prev);
rec_fset->doc = strdup(rec_fset->doc);
}
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
if (! rec_active) rec_active = rec_fset;
fix segfault when passing a docstring to def_property* (fixes #222)
2016-06-02 18:33:01 +00:00
}
Added write only property functions for issue #1142 (#1144) py::class_<T>'s `def_property` and `def_property_static` can now take a `nullptr` as the getter to allow a write-only property to be established (mirroring Python's `property()` built-in when `None` is given for the getter). This also updates properties to use the new nullptr constructor internally.
2017-11-07 16:35:27 +00:00
def_property_static_impl(name, fget, fset, rec_active);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
private:
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
/// Initialize holder object, variant 1: object derives from enable_shared_from_this
template <typename T>
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
static void init_holder(detail::instance *inst, detail::value_and_holder &v_h,
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
const holder_type * /* unused */, const std::enable_shared_from_this<T> * /* dummy */) {
improved shared pointer support (fixes #14)
2015-11-24 22:05:58 +00:00
try {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
auto sh = std::dynamic_pointer_cast<typename holder_type::element_type>(
v_h.value_ptr<type>()->shared_from_this());
Use dynamic cast for shared_from_this holder init Using a dynamic_cast instead of a static_cast is needed to safely cast from a base to a derived type. The previous static_pointer_cast isn't safe, however, when downcasting (and fails to compile when downcasting with virtual inheritance). Switching this to always use a dynamic_pointer_cast shouldn't incur any additional overhead when a static_pointer_cast is safe (i.e. when upcasting, or self-casting): compilers don't need RTTI checks in those cases.
2017-05-19 17:34:55 +00:00
if (sh) {
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
new (std::addressof(v_h.holder<holder_type>())) holder_type(std::move(sh));
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
v_h.set_holder_constructed();
Allow references to objects held by smart pointers (#533)
2016-12-07 01:36:44 +00:00
}
Use dynamic cast for shared_from_this holder init Using a dynamic_cast instead of a static_cast is needed to safely cast from a base to a derived type. The previous static_pointer_cast isn't safe, however, when downcasting (and fails to compile when downcasting with virtual inheritance). Switching this to always use a dynamic_pointer_cast shouldn't incur any additional overhead when a static_pointer_cast is safe (i.e. when upcasting, or self-casting): compilers don't need RTTI checks in those cases.
2017-05-19 17:34:55 +00:00
} catch (const std::bad_weak_ptr &) {}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
if (!v_h.holder_constructed() && inst->owned) {
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
new (std::addressof(v_h.holder<holder_type>())) holder_type(v_h.value_ptr<type>());
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
v_h.set_holder_constructed();
improved shared pointer support (fixes #14)
2015-11-24 22:05:58 +00:00
}
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
static void init_holder_from_existing(const detail::value_and_holder &v_h,
const holder_type *holder_ptr, std::true_type /*is_copy_constructible*/) {
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
new (std::addressof(v_h.holder<holder_type>())) holder_type(*reinterpret_cast<const holder_type *>(holder_ptr));
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
static void init_holder_from_existing(const detail::value_and_holder &v_h,
const holder_type *holder_ptr, std::false_type /*is_copy_constructible*/) {
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
new (std::addressof(v_h.holder<holder_type>())) holder_type(std::move(*const_cast<holder_type *>(holder_ptr)));
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
}
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
/// Initialize holder object, variant 2: try to construct from existing holder object, if possible
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
static void init_holder(detail::instance *inst, detail::value_and_holder &v_h,
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
const holder_type *holder_ptr, const void * /* dummy -- not enable_shared_from_this<T>) */) {
Allow references to objects held by smart pointers (#533)
2016-12-07 01:36:44 +00:00
if (holder_ptr) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
init_holder_from_existing(v_h, holder_ptr, std::is_copy_constructible<holder_type>());
v_h.set_holder_constructed();
always_construct_holder feature to support intrusively reference-counted types (#561) * always_construct_holder feature to support intrusively reference-counted types * added testcase
2016-12-15 22:44:23 +00:00
} else if (inst->owned || detail::always_construct_holder<holder_type>::value) {
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
new (std::addressof(v_h.holder<holder_type>())) holder_type(v_h.value_ptr<type>());
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
v_h.set_holder_constructed();
Allow references to objects held by smart pointers (#533)
2016-12-07 01:36:44 +00:00
}
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
}
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
/// Performs instance initialization including constructing a holder and registering the known
/// instance. Should be called as soon as the `type` value_ptr is set for an instance. Takes an
/// optional pointer to an existing holder to use; if not specified and the instance is
/// `.owned`, a new holder will be constructed to manage the value pointer.
static void init_instance(detail::instance *inst, const void *holder_ptr) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
auto v_h = inst->get_value_and_holder(detail::get_type_info(typeid(type)));
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
if (!v_h.instance_registered()) {
register_instance(inst, v_h.value_ptr(), v_h.type);
v_h.set_instance_registered();
}
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
init_holder(inst, v_h, (const holder_type *) holder_ptr, v_h.value_ptr<type>());
improved shared pointer support (fixes #14)
2015-11-24 22:05:58 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
/// Deallocates an instance; via holder, if constructed; otherwise via operator delete.
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
static void dealloc(detail::value_and_holder &v_h) {
if (v_h.holder_constructed()) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
v_h.holder<holder_type>().~holder_type();
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
v_h.set_holder_constructed(false);
}
else {
Add support custom sized operator deletes (#952) If a class doesn't provide a `T::operator delete(void *)` but does have a `T::operator delete(void *, size_t)` the latter is invoked by a `delete someT`. Pybind currently only look for and call the former; this commit adds detection and calling of the latter when the former doesn't exist.
2017-07-23 04:32:58 +00:00
detail::call_operator_delete(v_h.value_ptr<type>(), v_h.type->type_size);
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
}
v_h.value_ptr() = nullptr;
Initial commit
2015-07-05 18:05:44 +00:00
}
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
static detail::function_record *get_function_record(handle h) {
h = detail::get_function(h);
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
return h ? (detail::function_record *) reinterpret_borrow<capsule>(PyCFunction_GET_SELF(h.ptr()))
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
: nullptr;
minor redesign/generalization of def_property mechanism
2016-03-21 16:54:24 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
};
Update enum_ and bind_vector to new-style init and pickle Fixes #1046.
2017-08-30 21:40:55 +00:00
/// Binds an existing constructor taking arguments Args...
template <typename... Args> detail::initimpl::constructor<Args...> init() { return {}; }
/// Like `init<Args...>()`, but the instance is always constructed through the alias class (even
/// when not inheriting on the Python side).
template <typename... Args> detail::initimpl::alias_constructor<Args...> init_alias() { return {}; }
/// Binds a factory function as a constructor
template <typename Func, typename Ret = detail::initimpl::factory<Func>>
Ret init(Func &&f) { return {std::forward<Func>(f)}; }
/// Dual-argument factory function: the first function is called when no alias is needed, the second
/// when an alias is needed (i.e. due to python-side inheritance). Arguments must be identical.
template <typename CFunc, typename AFunc, typename Ret = detail::initimpl::factory<CFunc, AFunc>>
Ret init(CFunc &&c, AFunc &&a) {
return {std::forward<CFunc>(c), std::forward<AFunc>(a)};
}
/// Binds pickling functions `__getstate__` and `__setstate__` and ensures that the type
/// returned by `__getstate__` is the same as the argument accepted by `__setstate__`.
template <typename GetState, typename SetState>
detail::initimpl::pickle_factory<GetState, SetState> pickle(GetState &&g, SetState &&s) {
return {std::forward<GetState>(g), std::forward<SetState>(s)};
remove extra ';' [-Wpedantic]
2017-09-04 17:37:16 +00:00
}
Update enum_ and bind_vector to new-style init and pickle Fixes #1046.
2017-08-30 21:40:55 +00:00
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
NAMESPACE_BEGIN(detail)
struct enum_base {
enum_base(handle base, handle parent) : m_base(base), m_parent(parent) { }
PYBIND11_NOINLINE void init(bool is_arithmetic, bool is_convertible) {
m_base.attr("__entries") = dict();
auto property = handle((PyObject *) &PyProperty_Type);
auto static_property = handle((PyObject *) get_internals().static_property_type);
m_base.attr("__repr__") = cpp_function(
[](handle arg) -> str {
handle type = arg.get_type();
object type_name = type.attr("__name__");
dict entries = type.attr("__entries");
for (const auto &kv : entries) {
object other = kv.second[int_(0)];
if (other.equal(arg))
return pybind11::str("{}.{}").format(type_name, kv.first);
}
return pybind11::str("{}.???").format(type_name);
}, is_method(m_base)
);
m_base.attr("name") = property(cpp_function(
[](handle arg) -> str {
dict entries = arg.get_type().attr("__entries");
for (const auto &kv : entries) {
if (handle(kv.second[int_(0)]).equal(arg))
return pybind11::str(kv.first);
}
return "???";
}, is_method(m_base)
));
m_base.attr("__doc__") = static_property(cpp_function(
[](handle arg) -> std::string {
std::string docstring;
dict entries = arg.attr("__entries");
if (((PyTypeObject *) arg.ptr())->tp_doc)
docstring += std::string(((PyTypeObject *) arg.ptr())->tp_doc) + "\n\n";
docstring += "Members:";
for (const auto &kv : entries) {
auto key = std::string(pybind11::str(kv.first));
auto comment = kv.second[int_(1)];
docstring += "\n\n " + key;
if (!comment.is_none())
docstring += " : " + (std::string) pybind11::str(comment);
}
return docstring;
}
), none(), none(), "");
m_base.attr("__members__") = static_property(cpp_function(
[](handle arg) -> dict {
dict entries = arg.attr("__entries"), m;
for (const auto &kv : entries)
m[kv.first] = kv.second[int_(0)];
return m;
}), none(), none(), ""
);
Fix scoped enums comparison for equal/not equal cases (#1339) (#1571)
2018-10-24 09:18:58 +00:00
#define PYBIND11_ENUM_OP_STRICT(op, expr, strict_behavior) \
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
m_base.attr(op) = cpp_function( \
[](object a, object b) { \
if (!a.get_type().is(b.get_type())) \
Fix scoped enums comparison for equal/not equal cases (#1339) (#1571)
2018-10-24 09:18:58 +00:00
strict_behavior; \
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
return expr; \
}, \
is_method(m_base))
#define PYBIND11_ENUM_OP_CONV(op, expr) \
m_base.attr(op) = cpp_function( \
[](object a_, object b_) { \
int_ a(a_), b(b_); \
return expr; \
}, \
is_method(m_base))
if (is_convertible) {
PYBIND11_ENUM_OP_CONV("__eq__", !b.is_none() && a.equal(b));
PYBIND11_ENUM_OP_CONV("__ne__", b.is_none() || !a.equal(b));
if (is_arithmetic) {
PYBIND11_ENUM_OP_CONV("__lt__", a < b);
PYBIND11_ENUM_OP_CONV("__gt__", a > b);
PYBIND11_ENUM_OP_CONV("__le__", a <= b);
PYBIND11_ENUM_OP_CONV("__ge__", a >= b);
PYBIND11_ENUM_OP_CONV("__and__", a & b);
PYBIND11_ENUM_OP_CONV("__rand__", a & b);
PYBIND11_ENUM_OP_CONV("__or__", a | b);
PYBIND11_ENUM_OP_CONV("__ror__", a | b);
PYBIND11_ENUM_OP_CONV("__xor__", a ^ b);
PYBIND11_ENUM_OP_CONV("__rxor__", a ^ b);
}
} else {
Fix scoped enums comparison for equal/not equal cases (#1339) (#1571)
2018-10-24 09:18:58 +00:00
PYBIND11_ENUM_OP_STRICT("__eq__", int_(a).equal(int_(b)), return false);
PYBIND11_ENUM_OP_STRICT("__ne__", !int_(a).equal(int_(b)), return true);
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
if (is_arithmetic) {
Fix scoped enums comparison for equal/not equal cases (#1339) (#1571)
2018-10-24 09:18:58 +00:00
#define THROW throw type_error("Expected an enumeration of matching type!");
PYBIND11_ENUM_OP_STRICT("__lt__", int_(a) < int_(b), THROW);
PYBIND11_ENUM_OP_STRICT("__gt__", int_(a) > int_(b), THROW);
PYBIND11_ENUM_OP_STRICT("__le__", int_(a) <= int_(b), THROW);
PYBIND11_ENUM_OP_STRICT("__ge__", int_(a) >= int_(b), THROW);
#undef THROW
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
}
}
#undef PYBIND11_ENUM_OP_CONV
#undef PYBIND11_ENUM_OP_STRICT
object getstate = cpp_function(
[](object arg) { return int_(arg); }, is_method(m_base));
m_base.attr("__getstate__") = getstate;
m_base.attr("__hash__") = getstate;
}
PYBIND11_NOINLINE void value(char const* name_, object value, const char *doc = nullptr) {
dict entries = m_base.attr("__entries");
str name(name_);
if (entries.contains(name)) {
std::string type_name = (std::string) str(m_base.attr("__name__"));
throw value_error(type_name + ": element \"" + std::string(name_) + "\" already exists!");
}
entries[name] = std::make_pair(value, doc);
m_base.attr(name) = value;
}
PYBIND11_NOINLINE void export_values() {
dict entries = m_base.attr("__entries");
for (const auto &kv : entries)
m_parent.attr(kv.first) = kv.second[int_(0)];
}
handle m_base;
handle m_parent;
};
NAMESPACE_END(detail)
Initial commit
2015-07-05 18:05:44 +00:00
/// Binds C++ enumerations and enumeration classes to Python
template <typename Type> class enum_ : public class_<Type> {
public:
quench __setstate__ warnings (fixes #1522)
2018-09-14 10:07:47 +00:00
using Base = class_<Type>;
using Base::def;
using Base::attr;
using Base::def_property_readonly;
using Base::def_property_readonly_static;
make arithmetic operators of enum_ optional (#508) Following commit 90d278, the object code generated by the python bindings of nanogui (github.com/wjakob/nanogui) went up by a whopping 12%. It turns out that that project has quite a few enums where we don't really care about arithmetic operators. This commit thus partially reverts the effects of #503 by introducing an additional attribute py::arithmetic() that must be specified if the arithmetic operators are desired.
2016-11-17 22:24:47 +00:00
using Scalar = typename std::underlying_type<Type>::type;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
template <typename... Extra>
enum_(const handle &scope, const char *name, const Extra&... extra)
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
: class_<Type>(scope, name, extra...), m_base(*this, scope) {
Replace first_of_t with exactly_one_t
2017-03-29 09:55:18 +00:00
constexpr bool is_arithmetic = detail::any_of<std::is_same<arithmetic, Extra>...>::value;
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
constexpr bool is_convertible = std::is_convertible<Type, Scalar>::value;
m_base.init(is_arithmetic, is_convertible);
make arithmetic operators of enum_ optional (#508) Following commit 90d278, the object code generated by the python bindings of nanogui (github.com/wjakob/nanogui) went up by a whopping 12%. It turns out that that project has quite a few enums where we don't really care about arithmetic operators. This commit thus partially reverts the effects of #503 by introducing an additional attribute py::arithmetic() that must be specified if the arithmetic operators are desired.
2016-11-17 22:24:47 +00:00
Update enum_ and bind_vector to new-style init and pickle Fixes #1046.
2017-08-30 21:40:55 +00:00
def(init([](Scalar i) { return static_cast<Type>(i); }));
make arithmetic operators of enum_ optional (#508) Following commit 90d278, the object code generated by the python bindings of nanogui (github.com/wjakob/nanogui) went up by a whopping 12%. It turns out that that project has quite a few enums where we don't really care about arithmetic operators. This commit thus partially reverts the effects of #503 by introducing an additional attribute py::arithmetic() that must be specified if the arithmetic operators are desired.
2016-11-17 22:24:47 +00:00
def("__int__", [](Type value) { return (Scalar) value; });
enum_: fix implicit conversion on Python 2.7 Enumerations on Python 2.7 were not always implicitly converted to integers (depending on the target size). This patch adds a __long__ conversion function (only enabled on 2.7) which fixes this issue. The attached test case fails without this patch.
2017-04-28 12:46:52 +00:00
#if PY_MAJOR_VERSION < 3
def("__long__", [](Type value) { return (Scalar) value; });
#endif
quench __setstate__ warnings (fixes #1522)
2018-09-14 10:07:47 +00:00
cpp_function setstate(
[](Type &value, Scalar arg) { value = static_cast<Type>(arg); },
is_method(*this));
attr("__setstate__") = setstate;
Initial commit
2015-07-05 18:05:44 +00:00
}
/// Export enumeration entries into the parent scope
Expose enum_ entries as "__members__" read-only property. Getters get a copy.
2017-03-03 16:45:50 +00:00
enum_& export_values() {
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
m_base.export_values();
minor: have enum::export_values() return a reference to *this as usual
2016-11-04 15:51:14 +00:00
return *this;
Initial commit
2015-07-05 18:05:44 +00:00
}
/// Add an enumeration entry
support docstrings in enum::value() (#1160)
2017-11-16 21:24:36 +00:00
enum_& value(char const* name, Type value, const char *doc = nullptr) {
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
m_base.value(name, pybind11::cast(value, return_value_policy::copy), doc);
Initial commit
2015-07-05 18:05:44 +00:00
return *this;
}
Expose enum_ entries as "__members__" read-only property. Getters get a copy.
2017-03-03 16:45:50 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
private:
enum_: move most functionality to a non-template implementation This commit addresses an inefficiency in how enums are created in pybind11. Most of the enum_<> implementation is completely generic -- however, being a template class, it ended up instantiating vast amounts of essentially identical code in larger projects with many enums. This commit introduces a generic non-templated helper class that is compatible with any kind of enumeration. enum_ then becomes a thin wrapper around this new class. The new enum_<> API is designed to be 100% compatible with the old one.
2018-08-31 23:20:24 +00:00
detail::enum_base m_base;
Initial commit
2015-07-05 18:05:44 +00:00
};
NAMESPACE_BEGIN(detail)
keep_alive call policy (analogous to Boost.Python's with_custodian_and_ward, fixes #62)
2016-01-17 21:36:39 +00:00
Implement py::init_alias<>() constructors This commit adds support for forcing alias type initialization by defining constructors with `py::init_alias<arg1, arg2>()` instead of `py::init<arg1, arg2>()`. Currently py::init<> only results in Alias initialization if the type is extended in python, or the given arguments can't be used to construct the base type, but can be used to construct the alias. py::init_alias<>, in contrast, always invokes the constructor of the alias type. It looks like this was already the intention of `py::detail::init_alias`, which was forward-declared in 86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never finished: despite the existance of a .def method accepting it, the `detail::init_alias` class isn't actually defined anywhere. This commit completes the feature (or possibly repurposes it), allowing declaration of classes that will always initialize the trampoline which is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
Implement reference_internal with a keep_alive reference_internal requires an `instance` field to track the returned reference's parent, but that's just a duplication of what keep_alive<0,1> does, so use a keep alive to do this to eliminate the duplication.
2016-08-10 16:08:04 +00:00
inline void keep_alive_impl(handle nurse, handle patient) {
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
if (!nurse || !patient)
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("Could not activate keep_alive!");
keep_alive call policy (analogous to Boost.Python's with_custodian_and_ward, fixes #62)
2016-01-17 21:36:39 +00:00
Use handle::is_none() instead of raw ptrs
2016-08-29 01:38:47 +00:00
if (patient.is_none() || nurse.is_none())
Support keep_alive where nurse may be None For example keep_alive<0,1>() should work where the return value may sometimes be None. At present a "Could not allocate weak reference!" exception is thrown. Update documentation to clarify behaviour of keep_alive when nurse is None or does not support weak references.
2016-08-16 05:50:43 +00:00
return; /* Nothing to keep alive or nothing to be kept alive by */
keep_alive: don't fail when there is no patient
2016-04-25 01:25:13 +00:00
Hold strong references to keep_alive patients This fixes #856. Instead of the weakref trick, the internals structure holds an unordered_map from PyObject* to a vector of references. To avoid the cost of the unordered_map lookup for objects that don't have any keep_alive patients, a flag is added to each instance to indicate whether there is anything to do.
2017-06-24 12:58:42 +00:00
auto tinfo = all_type_info(Py_TYPE(nurse.ptr()));
if (!tinfo.empty()) {
/* It's a pybind-registered type, so we can store the patient in the
* internal list. */
add_patient(nurse.ptr(), patient.ptr());
}
else {
/* Fall back to clever approach based on weak references taken from
* Boost.Python. This is not used for pybind-registered types because
* the objects can be destroyed out-of-order in a GC pass. */
cpp_function disable_lifesupport(
[patient](handle weakref) { patient.dec_ref(); weakref.dec_ref(); });
keep_alive call policy (analogous to Boost.Python's with_custodian_and_ward, fixes #62)
2016-01-17 21:36:39 +00:00
Hold strong references to keep_alive patients This fixes #856. Instead of the weakref trick, the internals structure holds an unordered_map from PyObject* to a vector of references. To avoid the cost of the unordered_map lookup for objects that don't have any keep_alive patients, a flag is added to each instance to indicate whether there is anything to do.
2017-06-24 12:58:42 +00:00
weakref wr(nurse, disable_lifesupport);
keep_alive call policy (analogous to Boost.Python's with_custodian_and_ward, fixes #62)
2016-01-17 21:36:39 +00:00
Hold strong references to keep_alive patients This fixes #856. Instead of the weakref trick, the internals structure holds an unordered_map from PyObject* to a vector of references. To avoid the cost of the unordered_map lookup for objects that don't have any keep_alive patients, a flag is added to each instance to indicate whether there is anything to do.
2017-06-24 12:58:42 +00:00
patient.inc_ref(); /* reference patient and leak the weak reference */
(void) wr.release();
}
keep_alive call policy (analogous to Boost.Python's with_custodian_and_ward, fixes #62)
2016-01-17 21:36:39 +00:00
}
Pack all function call data into a single struct This cleans up the previous commit slightly by further reducing the function call arguments to a single struct (containing the function_record, arguments vector, and parent). Although this doesn't currently change anything, it does allow for future functionality to have a place for precalls to store temporary objects that need to be destroyed after a function call (whether or not the call succeeds). As a concrete example, with this change #625 could be easily implemented (I think) by adding a std::unique_ptr<gil_scoped_release> member to the `function_call` struct with a precall that actually constructs it. Without this, the precall can't do that: the postcall won't be invoked if the call throws an exception. This doesn't seems to affect the .so size noticeably (either way).
2017-01-30 18:34:38 +00:00
PYBIND11_NOINLINE inline void keep_alive_impl(size_t Nurse, size_t Patient, function_call &call, handle ret) {
Fix application of keep_alive policy to constructors (regression)
2017-09-04 11:49:19 +00:00
auto get_arg = [&](size_t n) {
if (n == 0)
return ret;
else if (n == 1 && call.init_self)
return call.init_self;
else if (n <= call.args.size())
return call.args[n - 1];
return handle();
};
keep_alive_impl(get_arg(Nurse), get_arg(Patient));
Implement reference_internal with a keep_alive reference_internal requires an `instance` field to track the returned reference's parent, but that's just a duplication of what keep_alive<0,1> does, so use a keep alive to do this to eliminate the duplication.
2016-08-10 16:08:04 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
inline std::pair<decltype(internals::registered_types_py)::iterator, bool> all_type_info_get_cache(PyTypeObject *type) {
auto res = get_internals().registered_types_py
Remove debugging The "z" wasn't meant to be committed; it meant the C++17 optimization here was never being used.
2017-07-29 07:53:45 +00:00
#ifdef __cpp_lib_unordered_map_try_emplace
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
.try_emplace(type);
#else
.emplace(type, std::vector<detail::type_info *>());
#endif
if (res.second) {
// New cache entry created; set up a weak reference to automatically remove it if the type
// gets destroyed:
weakref((PyObject *) type, cpp_function([type](handle wr) {
get_internals().registered_types_py.erase(type);
wr.dec_ref();
})).release();
}
return res;
}
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
template <typename Iterator, typename Sentinel, bool KeyIterator, return_value_policy Policy>
Add support for iterators with differing end type
2016-08-24 22:29:04 +00:00
struct iterator_state {
Iterator it;
Sentinel end;
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
bool first_or_done;
Switch to using prefix increment in make_iterator
2016-06-17 21:29:39 +00:00
};
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
NAMESPACE_END(detail)
Document make_iterator/make_key_iterator This adds brief API documentation for make_iterator/make_key_iterator, specifically mentioning that it requires InputIterators. Closes #734. [skip ci] (no code change here)
2017-03-18 16:34:21 +00:00
/// Makes a python iterator from a first and past-the-end C++ InputIterator.
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
template <return_value_policy Policy = return_value_policy::reference_internal,
typename Iterator,
Add support for iterators with differing end type
2016-08-24 22:29:04 +00:00
typename Sentinel,
fix issues with std::vector<bool> overload in STL (fixes #216)
2016-05-30 09:28:21 +00:00
typename ValueType = decltype(*std::declval<Iterator>()),
typename... Extra>
Add support for iterators with differing end type
2016-08-24 22:29:04 +00:00
iterator make_iterator(Iterator first, Sentinel last, Extra &&... extra) {
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
typedef detail::iterator_state<Iterator, Sentinel, false, Policy> state;
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
Multiple inheritance support
2016-09-11 11:00:40 +00:00
if (!detail::get_type_info(typeid(state), false)) {
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
class_<state>(handle(), "iterator", pybind11::module_local())
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
.def("__iter__", [](state &s) -> state& { return s; })
fix issues with std::vector<bool> overload in STL (fixes #216)
2016-05-30 09:28:21 +00:00
.def("__next__", [](state &s) -> ValueType {
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
if (!s.first_or_done)
Switch to using prefix increment in make_iterator
2016-06-17 21:29:39 +00:00
++s.it;
else
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
s.first_or_done = false;
if (s.it == s.end) {
s.first_or_done = true;
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
throw stop_iteration();
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
}
Switch to using prefix increment in make_iterator
2016-06-17 21:29:39 +00:00
return *s.it;
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
}, std::forward<Extra>(extra)..., Policy);
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
}
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
return cast(state{first, last, true});
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
}
allow iterators with different RV policies (fixes #388)
2016-09-06 04:06:31 +00:00
Document make_iterator/make_key_iterator This adds brief API documentation for make_iterator/make_key_iterator, specifically mentioning that it requires InputIterators. Closes #734. [skip ci] (no code change here)
2017-03-18 16:34:21 +00:00
/// Makes an python iterator over the keys (`.first`) of a iterator over pairs from a
/// first and past-the-end InputIterator.
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
template <return_value_policy Policy = return_value_policy::reference_internal,
typename Iterator,
Add support for iterators with differing end type
2016-08-24 22:29:04 +00:00
typename Sentinel,
Don't require operator-> for key iterators
2016-08-24 22:27:19 +00:00
typename KeyType = decltype((*std::declval<Iterator>()).first),
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
typename... Extra>
Add support for iterators with differing end type
2016-08-24 22:29:04 +00:00
iterator make_key_iterator(Iterator first, Sentinel last, Extra &&... extra) {
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
typedef detail::iterator_state<Iterator, Sentinel, true, Policy> state;
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
Multiple inheritance support
2016-09-11 11:00:40 +00:00
if (!detail::get_type_info(typeid(state), false)) {
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
class_<state>(handle(), "iterator", pybind11::module_local())
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
.def("__iter__", [](state &s) -> state& { return s; })
.def("__next__", [](state &s) -> KeyType {
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
if (!s.first_or_done)
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
++s.it;
else
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
s.first_or_done = false;
if (s.it == s.end) {
s.first_or_done = true;
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
throw stop_iteration();
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
}
Don't require operator-> for key iterators
2016-08-24 22:27:19 +00:00
return (*s.it).first;
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
}, std::forward<Extra>(extra)..., Policy);
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
}
Fix py::make_iterator's __next__() for past-the-end calls Fixes #896. From Python docs: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken."
2017-06-09 14:49:04 +00:00
return cast(state{first, last, true});
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
}
convenience wrapper for constructing iterators (fixes #142)
2016-04-13 21:33:00 +00:00
Document make_iterator/make_key_iterator This adds brief API documentation for make_iterator/make_key_iterator, specifically mentioning that it requires InputIterators. Closes #734. [skip ci] (no code change here)
2017-03-18 16:34:21 +00:00
/// Makes an iterator over values of an stl container or other container supporting
/// `std::begin()`/`std::end()`
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
template <return_value_policy Policy = return_value_policy::reference_internal,
typename Type, typename... Extra> iterator make_iterator(Type &value, Extra&&... extra) {
return make_iterator<Policy>(std::begin(value), std::end(value), extra...);
convenience overload for make_iterator()
2016-04-18 08:52:12 +00:00
}
Document make_iterator/make_key_iterator This adds brief API documentation for make_iterator/make_key_iterator, specifically mentioning that it requires InputIterators. Closes #734. [skip ci] (no code change here)
2017-03-18 16:34:21 +00:00
/// Makes an iterator over the keys (`.first`) of a stl map-like container supporting
/// `std::begin()`/`std::end()`
parameterize iterators by return value policy (fixes #388)
2016-09-10 07:00:50 +00:00
template <return_value_policy Policy = return_value_policy::reference_internal,
typename Type, typename... Extra> iterator make_key_iterator(Type &value, Extra&&... extra) {
return make_key_iterator<Policy>(std::begin(value), std::end(value), extra...);
Added pybind11::make_key_iterator for map iteration This allows exposing a dict-like interface to python code, allowing iteration over keys via: for k in custommapping: ... while still allowing iteration over pairs, so that you can also implement 'dict.items()' functionality which returns a pair iterator, allowing: for k, v in custommapping.items(): ... example-sequences-and-iterators is updated with a custom class providing both types of iteration.
2016-08-12 01:22:05 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
template <typename InputType, typename OutputType> void implicitly_convertible() {
make implicit conversions non-reentrant (fixes #1035) (#1037)
2017-08-28 14:34:06 +00:00
struct set_flag {
bool &flag;
set_flag(bool &flag) : flag(flag) { flag = true; }
~set_flag() { flag = false; }
};
moved processing of cpp_function arguments out of dispatch code The cpp_function class accepts a variadic argument, which was formerly processed twice -- once at registration time, and once in the dispatch lambda function. This is not only unnecessarily slow but also leads to code bloat since it adds to the object code generated for every bound function. This change removes the second pass at dispatch time. One noteworthy change of this commit is that default arguments are now constructed (and converted to Python objects) right at declaration time. Consider the following example: py::class_<MyClass>("MyClass") .def("myFunction", py::arg("arg") = SomeType(123)); In this case, the change means that pybind11 must already be set up to deal with values of the type 'SomeType', or an exception will be thrown. Another change is that the "preview" of the default argument in the function signature is generated using the __repr__ special method. If it is not available in this type, the signature may not be very helpful, i.e.: | myFunction(...) | Signature : (MyClass, arg : SomeType = <SomeType object at 0x101b7b080>) -> None One workaround (other than defining SomeType.__repr__) is to specify the human-readable preview of the default argument manually using the more cumbersome arg_t notation: py::class_<MyClass>("MyClass") .def("myFunction", py::arg_t<SomeType>("arg", SomeType(123), "SomeType(123)"));
2016-01-17 21:36:35 +00:00
auto implicit_caster = [](PyObject *obj, PyTypeObject *type) -> PyObject * {
make implicit conversions non-reentrant (fixes #1035) (#1037)
2017-08-28 14:34:06 +00:00
static bool currently_used = false;
if (currently_used) // implicit conversions are non-reentrant
return nullptr;
set_flag flag_helper(currently_used);
Fix pointer to reference error in type_caster on MSVC (#583)
2017-01-03 10:52:05 +00:00
if (!detail::make_caster<InputType>().load(obj, false))
Initial commit
2015-07-05 18:05:44 +00:00
return nullptr;
tuple args(1);
args[0] = obj;
PyObject *result = PyObject_Call((PyObject *) type, args.ptr(), nullptr);
if (result == nullptr)
PyErr_Clear();
return result;
};
Use detail::get_type_info() wherever sensible This reduces direct access to internals.registered_types_cpp to just a few places.
2016-10-23 14:43:03 +00:00
if (auto tinfo = detail::get_type_info(typeid(OutputType)))
tinfo->implicit_conversions.push_back(implicit_caster);
else
do more work with classes from pytypes.h (especially for STL container casting)
2016-01-17 21:36:41 +00:00
pybind11_fail("implicitly_convertible: Unable to find type " + type_id<OutputType>());
Initial commit
2015-07-05 18:05:44 +00:00
}
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
template <typename ExceptionTranslator>
void register_exception_translator(ExceptionTranslator&& translator) {
detail::get_internals().registered_exception_translators.push_front(
std::forward<ExceptionTranslator>(translator));
}
Style cleanup of javadoc-style comments This changes javadoc-style documenting comments from: /** Text starts here * and continues here */ to: /** * Test starts here * and continues here */ which looks a little better, and also matches the javadoc-recommended way of writing documenting comments.
2017-05-22 16:06:16 +00:00
/**
* Wrapper to generate a new Python exception type.
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
*
* This should only be used with PyErr_SetString for now.
* It is not (yet) possible to use as a py::base.
* Template type argument is reserved for future use.
*/
template <typename type>
class exception : public object {
public:
Add workaround for clang 3.3/3.4 As reported in #1349, clang before 3.5 can segfault on a function-local variable referenced inside a lambda. This moves the function-local static into a separate function that the lambda can invoke to avoid the issue. Fixes #1349
2018-04-05 14:04:15 +00:00
exception() = default;
exception constructor consistency improvements (fixes #492)
2016-11-16 16:59:56 +00:00
exception(handle scope, const char *name, PyObject *base = PyExc_Exception) {
std::string full_name = scope.attr("__name__").cast<std::string>() +
std::string(".") + name;
Avoid C-style const casts (#659) * Avoid C-style const casts Replace C-style casts that discard `const` with `const_cast` (and, where necessary, `reinterpret_cast` as well). * Warn about C-style const-discarding casts Change pybind11_enable_warnings to also enable `-Wcast-qual` (warn if a C-style cast discards `const`) by default. The previous commit should have gotten rid of all of these (at least, all the ones that tripped in my build, which included the tests), and this should discourage more from newly appearing.
2017-02-08 22:43:08 +00:00
m_ptr = PyErr_NewException(const_cast<char *>(full_name.c_str()), base, NULL);
exception constructor consistency improvements (fixes #492)
2016-11-16 16:59:56 +00:00
if (hasattr(scope, name))
pybind11_fail("Error during initialization: multiple incompatible "
"definitions with name \"" + std::string(name) + "\"");
scope.attr(name) = *this;
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
}
Added py::register_exception for simple case (#296) The custom exception handling added in PR #273 is robust, but is overly complex for declaring the most common simple C++ -> Python exception mapping that needs only to copy `what()`. This add a simpler `py::register_exception<CppExp>(module, "PyExp");` function that greatly simplifies the common basic case of translation of a simple CppException into a simple PythonException, while not removing the more advanced capabilities of defining custom exception handlers.
2016-09-16 06:04:15 +00:00
// Sets the current python exception to this exception object with the given message
void operator()(const char *message) {
PyErr_SetString(m_ptr, message);
}
Add support for user defined exception translators
2016-06-17 21:35:59 +00:00
};
Add workaround for clang 3.3/3.4 As reported in #1349, clang before 3.5 can segfault on a function-local variable referenced inside a lambda. This moves the function-local static into a separate function that the lambda can invoke to avoid the issue. Fixes #1349
2018-04-05 14:04:15 +00:00
NAMESPACE_BEGIN(detail)
// Returns a reference to a function-local static exception object used in the simple
// register_exception approach below. (It would be simpler to have the static local variable
// directly in register_exception, but that makes clang <3.5 segfault - issue #1349).
template <typename CppException>
exception<CppException> &get_exception_object() { static exception<CppException> ex; return ex; }
NAMESPACE_END(detail)
Style cleanup of javadoc-style comments This changes javadoc-style documenting comments from: /** Text starts here * and continues here */ to: /** * Test starts here * and continues here */ which looks a little better, and also matches the javadoc-recommended way of writing documenting comments.
2017-05-22 16:06:16 +00:00
/**
* Registers a Python exception in `m` of the given `name` and installs an exception translator to
Added py::register_exception for simple case (#296) The custom exception handling added in PR #273 is robust, but is overly complex for declaring the most common simple C++ -> Python exception mapping that needs only to copy `what()`. This add a simpler `py::register_exception<CppExp>(module, "PyExp");` function that greatly simplifies the common basic case of translation of a simple CppException into a simple PythonException, while not removing the more advanced capabilities of defining custom exception handlers.
2016-09-16 06:04:15 +00:00
* translate the C++ exception to the created Python exception using the exceptions what() method.
* This is intended for simple exception translations; for more complex translation, register the
* exception object and translator directly.
*/
exception constructor consistency improvements (fixes #492)
2016-11-16 16:59:56 +00:00
template <typename CppException>
exception<CppException> &register_exception(handle scope,
const char *name,
PyObject *base = PyExc_Exception) {
Add workaround for clang 3.3/3.4 As reported in #1349, clang before 3.5 can segfault on a function-local variable referenced inside a lambda. This moves the function-local static into a separate function that the lambda can invoke to avoid the issue. Fixes #1349
2018-04-05 14:04:15 +00:00
auto &ex = detail::get_exception_object<CppException>();
if (!ex) ex = exception<CppException>(scope, name, base);
Added py::register_exception for simple case (#296) The custom exception handling added in PR #273 is robust, but is overly complex for declaring the most common simple C++ -> Python exception mapping that needs only to copy `what()`. This add a simpler `py::register_exception<CppExp>(module, "PyExp");` function that greatly simplifies the common basic case of translation of a simple CppException into a simple PythonException, while not removing the more advanced capabilities of defining custom exception handlers.
2016-09-16 06:04:15 +00:00
register_exception_translator([](std::exception_ptr p) {
if (!p) return;
try {
std::rethrow_exception(p);
exception constructor consistency improvements (fixes #492)
2016-11-16 16:59:56 +00:00
} catch (const CppException &e) {
Add workaround for clang 3.3/3.4 As reported in #1349, clang before 3.5 can segfault on a function-local variable referenced inside a lambda. This moves the function-local static into a separate function that the lambda can invoke to avoid the issue. Fixes #1349
2018-04-05 14:04:15 +00:00
detail::get_exception_object<CppException>()(e.what());
Added py::register_exception for simple case (#296) The custom exception handling added in PR #273 is robust, but is overly complex for declaring the most common simple C++ -> Python exception mapping that needs only to copy `what()`. This add a simpler `py::register_exception<CppExp>(module, "PyExp");` function that greatly simplifies the common basic case of translation of a simple CppException into a simple PythonException, while not removing the more advanced capabilities of defining custom exception handlers.
2016-09-16 06:04:15 +00:00
}
});
return ex;
}
Add py::print() function Replicates Python API including keyword arguments.
2016-08-29 16:03:34 +00:00
NAMESPACE_BEGIN(detail)
PYBIND11_NOINLINE inline void print(tuple args, dict kwargs) {
auto strings = tuple(args.size());
for (size_t i = 0; i < args.size(); ++i) {
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
strings[i] = str(args[i]);
Add py::print() function Replicates Python API including keyword arguments.
2016-08-29 16:03:34 +00:00
}
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
auto sep = kwargs.contains("sep") ? kwargs["sep"] : cast(" ");
Extend attribute and item accessor interface using object_api
2016-09-08 15:02:04 +00:00
auto line = sep.attr("join")(strings);
Add py::print() function Replicates Python API including keyword arguments.
2016-08-29 16:03:34 +00:00
py::print robustness improvements, added import exception class
2016-10-13 08:34:52 +00:00
object file;
if (kwargs.contains("file")) {
file = kwargs["file"].cast<object>();
} else {
try {
file = module::import("sys").attr("stdout");
print traceback on failed import (#537)
2016-12-01 10:35:34 +00:00
} catch (const error_already_set &) {
py::print robustness improvements, added import exception class
2016-10-13 08:34:52 +00:00
/* If print() is called from code that is executed as
part of garbage collection during interpreter shutdown,
importing 'sys' can fail. Give up rather than crashing the
interpreter in this case. */
return;
}
}
Extend attribute and item accessor interface using object_api
2016-09-08 15:02:04 +00:00
auto write = file.attr("write");
Add py::print() function Replicates Python API including keyword arguments.
2016-08-29 16:03:34 +00:00
write(line);
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
write(kwargs.contains("end") ? kwargs["end"] : cast("\n"));
Add py::print() function Replicates Python API including keyword arguments.
2016-08-29 16:03:34 +00:00
py::print robustness improvements, added import exception class
2016-10-13 08:34:52 +00:00
if (kwargs.contains("flush") && kwargs["flush"].cast<bool>())
Extend attribute and item accessor interface using object_api
2016-09-08 15:02:04 +00:00
file.attr("flush")();
Add py::print() function Replicates Python API including keyword arguments.
2016-08-29 16:03:34 +00:00
}
NAMESPACE_END(detail)
template <return_value_policy policy = return_value_policy::automatic_reference, typename... Args>
void print(Args &&...args) {
auto c = detail::collect_arguments<policy>(std::forward<Args>(args)...);
detail::print(c.args(), c.kwargs());
}
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
#if defined(WITH_THREAD) && !defined(PYPY_VERSION)
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
/* The functions below essentially reproduce the PyGILState_* API using a RAII
* pattern, but there are a few important differences:
*
* 1. When acquiring the GIL from an non-main thread during the finalization
* phase, the GILState API blindly terminates the calling thread, which
* is often not what is wanted. This API does not do this.
*
* 2. The gil_scoped_release function can optionally cut the relationship
* of a PyThreadState and its associated thread, which allows moving it to
* another thread (this is a fairly rare/advanced use case).
*
* 3. The reference count of an acquired thread state can be controlled. This
* can be handy to prevent cases where callbacks issued from an external
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
* thread would otherwise constantly construct and destroy thread state data
* structures.
quenched warnings on windows, comments in gil_scoped_release
2016-05-26 12:29:31 +00:00
*
* See the Python bindings of NanoGUI (http://github.com/wjakob/nanogui) for an
* example which uses features 2 and 3 to migrate the Python thread of
* execution to another thread (to run the event loop on the original thread,
* in this case).
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
*/
Initial commit
2015-07-05 18:05:44 +00:00
class gil_scoped_acquire {
public:
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
PYBIND11_NOINLINE gil_scoped_acquire() {
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
auto const &internals = detail::get_internals();
Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) (#1454) * Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) * Changing Python version from 3.6 to 3.7 for Travis CI, to match brew's version of Python 3 * Introducing PYBIND11_ macros to switch between TLS and TSS API
2018-07-17 14:55:52 +00:00
tstate = (PyThreadState *) PYBIND11_TLS_GET_VALUE(internals.tstate);
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
if (!tstate) {
tstate = PyThreadState_New(internals.istate);
#if !defined(NDEBUG)
if (!tstate)
pybind11_fail("scoped_acquire: could not create thread state!");
#endif
tstate->gilstate_counter = 0;
Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) (#1454) * Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) * Changing Python version from 3.6 to 3.7 for Travis CI, to match brew's version of Python 3 * Introducing PYBIND11_ macros to switch between TLS and TSS API
2018-07-17 14:55:52 +00:00
PYBIND11_TLS_REPLACE_VALUE(internals.tstate, tstate);
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
} else {
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
release = detail::get_thread_state_unchecked() != tstate;
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
}
if (release) {
/* Work around an annoying assertion in PyThreadState_Swap */
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
#if defined(Py_DEBUG)
PyInterpreterState *interp = tstate->interp;
tstate->interp = nullptr;
#endif
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
PyEval_AcquireThread(tstate);
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
#if defined(Py_DEBUG)
tstate->interp = interp;
#endif
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
}
inc_ref();
}
void inc_ref() {
++tstate->gilstate_counter;
}
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
PYBIND11_NOINLINE void dec_ref() {
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
--tstate->gilstate_counter;
#if !defined(NDEBUG)
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
if (detail::get_thread_state_unchecked() != tstate)
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
pybind11_fail("scoped_acquire::dec_ref(): thread state must be current!");
if (tstate->gilstate_counter < 0)
pybind11_fail("scoped_acquire::dec_ref(): reference count underflow!");
#endif
if (tstate->gilstate_counter == 0) {
#if !defined(NDEBUG)
if (!release)
pybind11_fail("scoped_acquire::dec_ref(): internal error!");
#endif
PyThreadState_Clear(tstate);
PyThreadState_DeleteCurrent();
Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) (#1454) * Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) * Changing Python version from 3.6 to 3.7 for Travis CI, to match brew's version of Python 3 * Introducing PYBIND11_ macros to switch between TLS and TSS API
2018-07-17 14:55:52 +00:00
PYBIND11_TLS_DELETE_VALUE(detail::get_internals().tstate);
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
release = false;
}
}
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
PYBIND11_NOINLINE ~gil_scoped_acquire() {
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
dec_ref();
if (release)
PyEval_SaveThread();
}
private:
PyThreadState *tstate = nullptr;
bool release = true;
Initial commit
2015-07-05 18:05:44 +00:00
};
class gil_scoped_release {
public:
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
explicit gil_scoped_release(bool disassoc = false) : disassoc(disassoc) {
Fix GIL release and acquire when embedding the interpreter Fixes a race condition when multiple threads try to acquire the GIL before `detail::internals` have been initialized. `gil_scoped_release` is now tasked with initializing `internals` (guaranteed single-threaded) to ensure the safety of subsequent `acquire` calls from multiple threads.
2017-06-20 21:50:51 +00:00
// `get_internals()` must be called here unconditionally in order to initialize
// `internals.tstate` for subsequent `gil_scoped_acquire` calls. Otherwise, an
// initialization race could occur as multiple threads try `gil_scoped_acquire`.
const auto &internals = detail::get_internals();
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
tstate = PyEval_SaveThread();
Python 2.7.x fixes for new gil_scoped_release
2016-04-25 07:16:41 +00:00
if (disassoc) {
Fix GIL release and acquire when embedding the interpreter Fixes a race condition when multiple threads try to acquire the GIL before `detail::internals` have been initialized. `gil_scoped_release` is now tasked with initializing `internals` (guaranteed single-threaded) to ensure the safety of subsequent `acquire` calls from multiple threads.
2017-06-20 21:50:51 +00:00
auto key = internals.tstate;
Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) (#1454) * Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) * Changing Python version from 3.6 to 3.7 for Travis CI, to match brew's version of Python 3 * Introducing PYBIND11_ macros to switch between TLS and TSS API
2018-07-17 14:55:52 +00:00
PYBIND11_TLS_DELETE_VALUE(key);
Python 2.7.x fixes for new gil_scoped_release
2016-04-25 07:16:41 +00:00
}
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
}
~gil_scoped_release() {
if (!tstate)
return;
PyEval_RestoreThread(tstate);
Python 2.7.x fixes for new gil_scoped_release
2016-04-25 07:16:41 +00:00
if (disassoc) {
Use decltype to deduce return type of PyThread_create_key
2016-05-28 10:26:18 +00:00
auto key = detail::get_internals().tstate;
Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) (#1454) * Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) * Changing Python version from 3.6 to 3.7 for Travis CI, to match brew's version of Python 3 * Introducing PYBIND11_ macros to switch between TLS and TSS API
2018-07-17 14:55:52 +00:00
PYBIND11_TLS_REPLACE_VALUE(key, tstate);
Python 2.7.x fixes for new gil_scoped_release
2016-04-25 07:16:41 +00:00
}
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
}
private:
PyThreadState *tstate;
bool disassoc;
Initial commit
2015-07-05 18:05:44 +00:00
};
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
#elif defined(PYPY_VERSION)
class gil_scoped_acquire {
PyGILState_STATE state;
public:
gil_scoped_acquire() { state = PyGILState_Ensure(); }
~gil_scoped_acquire() { PyGILState_Release(state); }
};
class gil_scoped_release {
PyThreadState *state;
public:
gil_scoped_release() { state = PyEval_SaveThread(); }
~gil_scoped_release() { PyEval_RestoreThread(state); }
};
significant redesign of GIL state handling
2016-04-25 01:26:15 +00:00
#else
class gil_scoped_acquire { };
class gil_scoped_release { };
deal with Python versions compiled without thread support (fixes #81)
2016-01-25 19:22:44 +00:00
#endif
Initial commit
2015-07-05 18:05:44 +00:00
use pybind11::gil_scoped_acquire instead of PyGILState_*
2016-11-24 22:11:02 +00:00
error_already_set::~error_already_set() {
Simplify error_already_set `error_already_set` is more complicated than it needs to be, partly because it manages reference counts itself rather than using `py::object`, and partly because it tries to do more exception clearing than is needed. This commit greatly simplifies it, and fixes #927. Using `py::object` instead of `PyObject *` means we can rely on implicit copy/move constructors. The current logic did both a `PyErr_Clear` on deletion *and* a `PyErr_Fetch` on creation. I can't see how the `PyErr_Clear` on deletion is ever useful: the `Fetch` on creation itself clears the error, so the only way doing a `PyErr_Clear` on deletion could do anything if is some *other* exception was raised while the `error_already_set` object was alive--but in that case, clearing some other exception seems wrong. (Code that is worried about an exception handler raising another exception would already catch a second `error_already_set` from exception code). The destructor itself called `clear()`, but `clear()` was a little bit more paranoid that needed: it called `restore()` to restore the currently captured error, but then immediately cleared it, using the `PyErr_Restore` to release the references. That's unnecessary: it's valid for us to release the references manually. This updates the code to simply release the references on the three objects (preserving the gil acquire). `clear()`, however, also had the side effect of clearing the current error, even if the current `error_already_set` didn't have a current error (e.g. because of a previous `restore()` or `clear()` call). I don't really see how clearing the error here can ever actually be useful: the only way the current error could be set is if you called `restore()` (in which case the current stored error-related members have already been released), or if some *other* code raised the error, in which case `clear()` on *this* object is clearing an error for which it shouldn't be responsible. Neither of those seem like intentional or desirable features, and manually requesting deletion of the stored references similarly seems pointless, so I've just made `clear()` an empty method and marked it deprecated. This also fixes a minor potential issue with the destruction: it is technically possible for `value` to be null (though this seems likely to be rare in practice); this updates the check to look at `type` which will always be non-null for a `Fetch`ed exception. This also adds error_already_set round-trip throw tests to the test suite.
2017-07-21 03:14:33 +00:00
if (type) {
Properly report exceptions thrown during module initialization. If an exception is thrown during module initialization, the error_already_set destructor will try to call `get_internals()` *after* setting Python's error indicator, resulting in a `SystemError: ... returned with an error set`. Fix that by temporarily stashing away the error indicator in the destructor.
2018-04-17 02:08:45 +00:00
error_scope scope;
use pybind11::gil_scoped_acquire instead of PyGILState_*
2016-11-24 22:11:02 +00:00
gil_scoped_acquire gil;
Simplify error_already_set `error_already_set` is more complicated than it needs to be, partly because it manages reference counts itself rather than using `py::object`, and partly because it tries to do more exception clearing than is needed. This commit greatly simplifies it, and fixes #927. Using `py::object` instead of `PyObject *` means we can rely on implicit copy/move constructors. The current logic did both a `PyErr_Clear` on deletion *and* a `PyErr_Fetch` on creation. I can't see how the `PyErr_Clear` on deletion is ever useful: the `Fetch` on creation itself clears the error, so the only way doing a `PyErr_Clear` on deletion could do anything if is some *other* exception was raised while the `error_already_set` object was alive--but in that case, clearing some other exception seems wrong. (Code that is worried about an exception handler raising another exception would already catch a second `error_already_set` from exception code). The destructor itself called `clear()`, but `clear()` was a little bit more paranoid that needed: it called `restore()` to restore the currently captured error, but then immediately cleared it, using the `PyErr_Restore` to release the references. That's unnecessary: it's valid for us to release the references manually. This updates the code to simply release the references on the three objects (preserving the gil acquire). `clear()`, however, also had the side effect of clearing the current error, even if the current `error_already_set` didn't have a current error (e.g. because of a previous `restore()` or `clear()` call). I don't really see how clearing the error here can ever actually be useful: the only way the current error could be set is if you called `restore()` (in which case the current stored error-related members have already been released), or if some *other* code raised the error, in which case `clear()` on *this* object is clearing an error for which it shouldn't be responsible. Neither of those seem like intentional or desirable features, and manually requesting deletion of the stored references similarly seems pointless, so I've just made `clear()` an empty method and marked it deprecated. This also fixes a minor potential issue with the destruction: it is technically possible for `value` to be null (though this seems likely to be rare in practice); this updates the check to look at `type` which will always be non-null for a `Fetch`ed exception. This also adds error_already_set round-trip throw tests to the test suite.
2017-07-21 03:14:33 +00:00
type.release().dec_ref();
value.release().dec_ref();
trace.release().dec_ref();
use pybind11::gil_scoped_acquire instead of PyGILState_*
2016-11-24 22:11:02 +00:00
}
}
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
inline function get_type_overload(const void *this_ptr, const detail::type_info *this_type, const char *name) {
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
handle self = detail::get_object_handle(this_ptr, this_type);
if (!self)
don't throw an exception when python deallocates an object which still exists on the C++ side
2015-10-01 16:37:26 +00:00
return function();
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
handle type = self.get_type();
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
auto key = std::make_pair(type.ptr(), name);
address issue with virtual function dispatch (fixes #159)
2016-04-11 16:13:08 +00:00
/* Cache functions that aren't overloaded in Python to avoid
many costly Python dictionary lookups below */
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
auto &cache = detail::get_internals().inactive_overload_cache;
if (cache.find(key) != cache.end())
return function();
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
function overload = getattr(self, name, function());
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
if (overload.is_cpp_function()) {
cache.insert(key);
return function();
}
added new type pybind11::bytes, cleanup of various macros (fixes #49)
2016-01-17 21:36:37 +00:00
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
/* Don't call dispatch code if invoked from overridden function.
Unfortunately this doesn't work on PyPy. */
#if !defined(PYPY_VERSION)
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
PyFrameObject *frame = PyThreadState_Get()->frame;
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
if (frame && (std::string) str(frame->f_code->co_name) == name &&
address issue with virtual function dispatch (fixes #159)
2016-04-11 16:13:08 +00:00
frame->f_code->co_argcount > 0) {
PyFrame_FastToLocals(frame);
PyObject *self_caller = PyDict_GetItem(
frame->f_locals, PyTuple_GET_ITEM(frame->f_code->co_varnames, 0));
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
if (self_caller == self.ptr())
address issue with virtual function dispatch (fixes #159)
2016-04-11 16:13:08 +00:00
return function();
}
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
#else
/* PyPy currently doesn't provide a detailed cpyext emulation of
frame objects, so we have to emulate this using Python. This
is going to be slow..*/
dict d; d["self"] = self; d["name"] = pybind11::str(name);
PyObject *result = PyRun_String(
"import inspect\n"
"frame = inspect.currentframe()\n"
"if frame is not None:\n"
" frame = frame.f_back\n"
" if frame is not None and str(frame.f_code.co_name) == name and "
"frame.f_code.co_argcount > 0:\n"
" self_caller = frame.f_locals[frame.f_code.co_varnames[0]]\n"
" if self_caller == self:\n"
" self = None\n",
Py_file_input, d.ptr(), d.ptr());
if (result == nullptr)
throw error_already_set();
Deprecate handle::operator== in favor of object_api::is
2017-02-08 00:01:56 +00:00
if (d["self"].is_none())
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
return function();
Py_DECREF(result);
#endif
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
return overload;
}
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
template <class T> function get_overload(const T *this_ptr, const char *name) {
Use detail::get_type_info() wherever sensible This reduces direct access to internals.registered_types_cpp to just a few places.
2016-10-23 14:43:03 +00:00
auto tinfo = detail::get_type_info(typeid(T));
return tinfo ? get_type_overload(this_ptr, tinfo, name) : function();
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
}
Fix template trampoline overload lookup failure Problem ======= The template trampoline pattern documented in PR #322 has a problem with virtual method overloads in intermediate classes in the inheritance chain between the trampoline class and the base class. For example, consider the following inheritance structure, where `B` is the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an intermediate class adding A's methods into the trampoline: PyB<B> -> PyA<B> -> B -> A Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in it to overload the virtual `A::some_method()`. If a Python class `C` is defined that inherits from the pybind11-registered `B` and tries to provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared in PyA<B> fails to find this overloaded method, and thus never invoke it (or, if pure virtual and not overridden in PyB<B>, raises an exception). This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro simply calls `get_overload(this, name)`; `get_overload()` then uses the inferred type of `this` to do a type lookup in `registered_types_cpp`. This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a result, the overload fails and we get a failed overload lookup. The fix ======= The fix is relatively simple: we can cast `this` passed to `get_overload()` to a `const B *`, which lets get_overload look up the correct class. Since trampoline classes should be derived from `B` classes anyway, this cast should be perfectly safe. This does require adding the class name as an argument to the PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures unchanged.
2016-08-29 22:16:46 +00:00
#define PYBIND11_OVERLOAD_INT(ret_type, cname, name, ...) { \
last breaking change: be consistent about the project name
2015-10-15 16:13:33 +00:00
pybind11::gil_scoped_acquire gil; \
Fix template trampoline overload lookup failure Problem ======= The template trampoline pattern documented in PR #322 has a problem with virtual method overloads in intermediate classes in the inheritance chain between the trampoline class and the base class. For example, consider the following inheritance structure, where `B` is the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an intermediate class adding A's methods into the trampoline: PyB<B> -> PyA<B> -> B -> A Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in it to overload the virtual `A::some_method()`. If a Python class `C` is defined that inherits from the pybind11-registered `B` and tries to provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared in PyA<B> fails to find this overloaded method, and thus never invoke it (or, if pure virtual and not overridden in PyB<B>, raises an exception). This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro simply calls `get_overload(this, name)`; `get_overload()` then uses the inferred type of `this` to do a type lookup in `registered_types_cpp`. This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a result, the overload fails and we get a failed overload lookup. The fix ======= The fix is relatively simple: we can cast `this` passed to `get_overload()` to a `const B *`, which lets get_overload look up the correct class. Since trampoline classes should be derived from `B` classes anyway, this cast should be perfectly safe. This does require adding the class name as an argument to the PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures unchanged.
2016-08-29 22:16:46 +00:00
pybind11::function overload = pybind11::get_overload(static_cast<const cname *>(this), name); \
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
if (overload) { \
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
auto o = overload(__VA_ARGS__); \
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
if (pybind11::detail::cast_is_temporary_value_reference<ret_type>::value) { \
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
static pybind11::detail::overload_caster_t<ret_type> caster; \
return pybind11::detail::cast_ref<ret_type>(std::move(o), caster); \
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
} \
else return pybind11::detail::cast_safe<ret_type>(std::move(o)); \
} \
}
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
PYBIND11_OVERLOAD_NAME and PYBIND11_OVERLOAD_PURE_NAME (fixes #205)
2016-05-24 21:42:05 +00:00
#define PYBIND11_OVERLOAD_NAME(ret_type, cname, name, fn, ...) \
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
PYBIND11_OVERLOAD_INT(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), name, __VA_ARGS__) \
PYBIND11_OVERLOAD_NAME and PYBIND11_OVERLOAD_PURE_NAME (fixes #205)
2016-05-24 21:42:05 +00:00
return cname::fn(__VA_ARGS__)
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
PYBIND11_OVERLOAD_NAME and PYBIND11_OVERLOAD_PURE_NAME (fixes #205)
2016-05-24 21:42:05 +00:00
#define PYBIND11_OVERLOAD_PURE_NAME(ret_type, cname, name, fn, ...) \
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
PYBIND11_OVERLOAD_INT(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), name, __VA_ARGS__) \
Fix class name in overload failure message
2018-02-28 03:43:16 +00:00
pybind11::pybind11_fail("Tried to call pure virtual function \"" PYBIND11_STRINGIFY(cname) "::" name "\"");
PYBIND11_OVERLOAD_NAME and PYBIND11_OVERLOAD_PURE_NAME (fixes #205)
2016-05-24 21:42:05 +00:00
#define PYBIND11_OVERLOAD(ret_type, cname, fn, ...) \
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
PYBIND11_OVERLOAD_NAME(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), #fn, fn, __VA_ARGS__)
PYBIND11_OVERLOAD_NAME and PYBIND11_OVERLOAD_PURE_NAME (fixes #205)
2016-05-24 21:42:05 +00:00
#define PYBIND11_OVERLOAD_PURE(ret_type, cname, fn, ...) \
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
PYBIND11_OVERLOAD_PURE_NAME(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), #fn, fn, __VA_ARGS__)
support for overriding virtual functions
2015-10-01 14:46:03 +00:00
Force hidden visibility on pybind code This adds a PYBIND11_NAMESPACE macro that expands to the `pybind11` namespace with hidden visibility under gcc-type compilers, and otherwise to the plain `pybind11`. This then forces hidden visibility on everything in pybind, solving the visibility issues discussed at end end of #949.
2017-08-10 16:03:29 +00:00
NAMESPACE_END(PYBIND11_NAMESPACE)
Initial commit
2015-07-05 18:05:44 +00:00
#if defined(_MSC_VER)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
# pragma warning(pop)
Get pybind11 test suite to compile on the Intel compiler (more or less..) - ICPC can't handle the NCVirt trampoline which returns a non-copyable type, which is likely due to a constexpr/SFINAE issue. This disables the test on that compiler so that at least the rest can be tested.
2016-08-24 23:43:33 +00:00
#elif defined(__INTEL_COMPILER)
/* Leave ignored warnings on */
fix incorrect in macro if statement
2016-05-01 18:47:49 +00:00
#elif defined(__GNUG__) && !defined(__clang__)
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
# pragma GCC diagnostic pop
Initial commit
2015-07-05 18:05:44 +00:00
#endif
Reference in New Issue Copy Permalink