"library/vscode:/vscode.git/clone" did not exist on "d08aa99e440b69b3692357b4a4b5daaf9e5b0500"
- 17 Nov, 2016 4 commits
-
-
Dean Moldovan authored
* `array_t(const object &)` now throws on error * `array_t::ensure()` is intended for casters —- old constructor is deprecated * `array` and `array_t` get default constructors (empty array) * `array` gets a converting constructor * `py::isinstance<array_T<T>>()` checks the type (but not flags) There is only one special thing which must remain: `array_t` gets its own `type_caster` specialization which uses `ensure` instead of a simple check.
-
Dean Moldovan authored
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.
-
Dean Moldovan authored
* 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.
-
Dean Moldovan authored
Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
-
- 16 Nov, 2016 3 commits
-
-
Wenzel Jakob authored
-
Sylvain Corlay authored
* Also added unsafe version without checks
-
Pim Schellart authored
* Allow enums to be ordered * Support binary operators
-
- 15 Nov, 2016 4 commits
-
-
Ivan Smirnov authored
* Incref returned None in std::optional type caster * Add type casters for nullopt_t * Add a test for nullopt_t
-
Alexander Stukowski authored
Added the docstring_options class, which gives global control over the generation of docstrings and function signatures.
-
Jason Rhinelander authored
This commit includes the following changes: * Don't provide make_copy_constructor for non-copyable container make_copy_constructor currently fails for various stl containers (e.g. std::vector, std::unordered_map, std::deque, etc.) when the container's value type (e.g. the "T" or the std::pair<K,T> for a map) is non-copyable. This adds an override that, for types that look like containers, also requires that the value_type be copyable. * stl_bind.h: make bind_{vector,map} work for non-copy-constructible types Most stl_bind modifiers require copying, so if the type isn't copy constructible, we provide a read-only interface instead. In practice, this means that if the type is non-copyable, it will be, for all intents and purposes, read-only from the Python side (but currently it simply fails to compile with such a container). It is still possible for the caller to provide an interface manually (by defining methods on the returned class_ object), but this isn't something stl_bind can handle because the C++ code to construct values is going to be highly dependent on the container value_type. * stl_bind: copy only for arithmetic value types For non-primitive types, we may well be copying some complex type, when returning by reference is more appropriate. This commit returns by internal reference for all but basic arithmetic types. * Return by reference whenever possible Only if we definitely can't--i.e. std::vector<bool>--because v[i] returns something that isn't a T& do we copy; for everything else, we return by reference. For the map case, we can always return by reference (at least for the default stl map/unordered_map). -
Wenzel Jakob authored
-
- 12 Nov, 2016 1 commit
-
-
Wenzel Jakob authored
-
- 08 Nov, 2016 1 commit
-
-
Wenzel Jakob authored
-
- 07 Nov, 2016 1 commit
-
-
Wenzel Jakob authored
-
- 06 Nov, 2016 1 commit
-
-
Jason Rhinelander authored
If we need to initialize a holder around an unowned instance, and the holder type is non-copyable (i.e. a unique_ptr), we currently construct the holder type around the value pointer, but then never actually destruct the holder: the holder destructor is called only for the instance that actually has `inst->owned = true` set. This seems no pointer, however, in creating such a holder around an unowned instance: we never actually intend to use anything that the unique_ptr gives us: and, in fact, do not want the unique_ptr (because if it ever actually got destroyed, it would cause destruction of the wrapped pointer, despite the fact that that wrapped pointer isn't owned). This commit changes the logic to only create a unique_ptr holder if we actually own the instance, and to destruct via the constructed holder whenever we have a constructed holder--which will now only be the case for owned-unique-holder or shared-holder types. Other changes include: * Added test for non-movable holder constructor/destructor counts The three alive assertions now pass, before #478 they fail with counts of 2/2/1 respectively, because of the unique_ptr that we don't want and don't destroy (because we don't *want* its destructor to run). * Return cstats reference; fix ConstructStats doc Small cleanup to the #478 test code, and fix to the ConstructStats documentation (the static method definition should use `reference` not `reference_internal`). * Rename inst->constructed to inst->holder_constructed This makes it clearer exactly what it's referring to.
-
- 04 Nov, 2016 2 commits
-
-
Wenzel Jakob authored
-
Jason Rhinelander authored
There are now more places than just descr.h that make use of these. The new macro isn't quite the same: the old one only tested for a couple features, while the new one checks for the __cplusplus version (but doesn't even try to enable C++14 for MSVC/ICC). g++ 7 adds <optional>, but including it in C++14 mode isn't allowed (just as including <experimental/optional> isn't allowed in C++11 mode). (This wasn't triggered in g++-6 because it doesn't provide <optional> yet.)
-
- 03 Nov, 2016 6 commits
-
-
Jason Rhinelander authored
-
Ivan Smirnov authored
* Add type caster for std::experimental::optional * Add tests for std::experimental::optional * Support both <optional> / <experimental/optional> * Mention std{::experimental,}::optional in the docs -
Wenzel Jakob authored
-
Ivan Smirnov authored
(avoid code bloat if possible)
-
Ivan Smirnov authored
NumPy internals are stored under "_numpy_internals" key.
-
Ivan Smirnov authored
-
- 01 Nov, 2016 2 commits
-
-
Ivan Smirnov authored
PYBIND11_NUMPY_DTYPE_EX(Type, F1, "N1", F2, "N2", ...)
-
Dean Moldovan authored
* 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)`.
-
- 27 Oct, 2016 1 commit
-
-
Wenzel Jakob authored
The current integer caster was unnecessarily strict and rejected various kinds of NumPy integer types when calling C++ functions expecting normal integers. This relaxes the current behavior.
-
- 25 Oct, 2016 1 commit
-
-
Jason Rhinelander authored
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.
-
- 24 Oct, 2016 1 commit
-
-
Ivan Smirnov authored
This reduces direct access to internals.registered_types_cpp to just a few places.
-
- 23 Oct, 2016 1 commit
-
-
Ivan Smirnov authored
This avoid a hashmap lookup since the pointer to the list of direct converters is now cached in the typeinfo.
-
- 22 Oct, 2016 5 commits
-
-
Wenzel Jakob authored
-
Ivan Smirnov authored
-
Ivan Smirnov authored
-
Ivan Smirnov authored
-
Ivan Smirnov authored
-
- 21 Oct, 2016 1 commit
-
-
Dean Moldovan authored
Making `cppfunction` explicit broke `def_property` and friends. The added tests would not compile without an implicit `cppfunction`.
-
- 20 Oct, 2016 5 commits
-
-
Ben North authored
type_caster_generic::cast(): The values of wrapper->value wrapper->owned are incorrect in the case that a return value policy of 'copy' is requested but there is no copy-constructor. (Similarly 'move'.) In particular, if the source object is a static instance, the destructor of the 'object' 'inst' leads to class_::dealloc() which incorrectly attempts to 'delete' the static instance. This commit re-arranges the code to be clearer as to what the values of 'value' and 'owned' should be in the various cases. Behaviour is different to previous code only in two situations: policy = copy but no copy-ctor: Old code leaves 'value = src, owned = true', which leads to trouble. New code leaves 'value = nullptr, owned = false', which is correct. policy = move but no move- or copy-ctor: old code leaves 'value = src, owned = true', which leads to trouble. New code leaves 'value = nullptr, owned = false', which is correct. -
Ivan Smirnov authored
-
Ivan Smirnov authored
-
Ivan Smirnov authored
-
Ivan Smirnov authored
-