9 Commits

Author SHA1 Message Date
kingofpayne
12e8774bc9 Added support for list insertion. (#1888) 2019-08-19 23:00:36 +02:00
Sergei Lebedev
08b0bda4bc Added set::contains and generalized dict::contains (#1884)
Dynamically resolving __contains__ on each call is wasteful since set
has a public PySet_Contains function.
2019-08-16 21:32:27 +02:00
Wenzel Jakob
b4b2292488 relax operator[] for tuples, lists, and sequences
object_api::operator[] has a powerful overload for py::handle that can
accept slices, tuples (for NumPy), etc.

Lists, sequences, and tuples provide their own specialized operator[],
which unfortunately disables this functionality. This is accidental, and
the purpose of this commit is to re-enable the more general behavior.

This commit is tangentially related to the previous one in that it makes
py::handle/py::object et al. behave more like their Python counterparts.
2018-09-11 22:08:26 +02:00
Wenzel Jakob
067100201f object_api: support the number protocol
This commit revamps the object_api class so that it maps most C++
operators to their Python analogs. This makes it possible to, e.g.
perform arithmetic using a py::int_ or py::array.
2018-09-11 22:08:26 +02:00
Jason Rhinelander
5c7a290d37 Fix new flake8 E741 error from using l variable
The just-updated flake8 package hits a bunch of:

    E741 ambiguous variable name 'l'

warnings.  This commit renames them all from `l` to `lst` (they are all
list values) to avoid the error.
2017-10-25 08:18:21 -03:00
Dean Moldovan
2cf87a54d8 Fix implicit conversion of accessors to types derived from py::object
Fixes #1069.
2017-09-11 10:09:32 +02:00
Bruce Merry
37de2da9dd Access C++ hash functions from Python and vice versa (#1034)
There are two separate additions:

1. `py::hash(obj)` is equivalent to the Python `hash(obj)`.
2. `.def(hash(py::self))` registers the hash function defined by
   `std::hash<T>` as the Python hash function.
2017-08-30 14:22:00 +02:00
Jason Rhinelander
373da82486 Make PYBIND11_OBJECT_CVT only convert if the type check fails
Currently types that are capable of conversion always call their convert
function when invoked with a `py::object` which is actually the correct
type.  This means that code such as `py::cast<py::list>(obj)` and
`py::list l(obj.attr("list"))` make copies, which was an oversight
rather than an intentional feature.

While at first glance there might be something behind having
`py::list(obj)` make a copy (as it would in Python), this would be
inconsistent when you dig a little deeper because `py::list(l)`
*doesn't* make a copy for an existing `py::list l`, and having an
inconsistency within C++ would be worse than a C++ <-> Python
inconsistency.

It is possible to get around the copying using a
`reinterpret_borrow<list>(o)` (and this commit fixes one place, in
`embed.h`, that does so), but that seems a misuse of
`reinterpret_borrow`, which is really supposed to be just for dealing
with raw python-returned values, not `py::object`-derived wrappers which
are supposed to be higher level.

This changes the constructor of such converting types (i.e. anything
using PYBIND11_OBJECT_CVT -- `str`, `bool_`, `int_`, `float_`, `tuple`,
`dict`, `list`, `set`, `memoryview`) to reference rather than copy when
the check function passes.

It also adds an `object &&` constructor that is slightly more efficient
by avoiding an inc_ref when the check function passes.
2017-08-04 10:14:55 -04:00
Dean Moldovan
83e328f58c Split test_python_types.cpp into builtin_casters, stl and pytypes 2017-06-27 10:38:41 +02:00