This patch adds an extra base handle parameter to most ``py::array`` and
``py::array_t<>`` constructors. If specified along with a pointer to
data, the base object will be registered within NumPy, which increases
the base's reference count. This feature is useful to create shallow
copies of C++ or Python arrays while ensuring that the owners of the
underlying can't be garbage collected while referenced by NumPy.
The commit also adds a simple test function involving a ``wrap()``
function that creates shallow copies of various N-D arrays.
Python 3.5 can often import pybind11 modules compiled compiled for
Python 3.4 (i.e. all symbols can be resolved), but this leads to crashes
later on due to changes in various Python-internal data structures. This
commit adds an extra sanity check to prevent a successful import when
the Python versions don't match.
This fixes an issue that can arise when forwarding (*args, **kwargs)
captured from a pybind11-bound function call to another Python function.
When the initial function call includes no keyword arguments, the
py::kwargs field is set to nullptr and causes a crash later on.
PR #425 removed the bool operator from attribute accessors. This is
likely in use by existing code as it was the only way before #425 added
the `hasattr` function to check for the existence of an attribute, via:
if (obj.attr("foo")) { ... }
This commit adds it back in for attr and item accessors, but with a
deprecation warning to use `hasattr(obj, ...)` or `obj.contains(...)`
instead.
`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.
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.
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.
