1. 16 Oct, 2016 2 commits
    • Wenzel Jakob's avatar
      Merge pull request #449 from jagerman/no-implicit-conversions · 135fd149
      Wenzel Jakob authored
      Disable most implicit conversion constructors
      135fd149
    • Jason Rhinelander's avatar
      Disable most implicit conversion constructors · 12d76600
      Jason Rhinelander authored
      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.
      12d76600
  2. 15 Oct, 2016 2 commits
  3. 14 Oct, 2016 3 commits
  4. 13 Oct, 2016 6 commits
  5. 12 Oct, 2016 3 commits
  6. 11 Oct, 2016 1 commit
  7. 09 Oct, 2016 6 commits
  8. 08 Oct, 2016 1 commit
    • Wenzel Jakob's avatar
      unpacking_collector: allow nullptr-valued kwargs argument · e71ab8f4
      Wenzel Jakob authored
      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.
      e71ab8f4
  9. 07 Oct, 2016 1 commit
  10. 02 Oct, 2016 2 commits
  11. 30 Sep, 2016 2 commits
  12. 29 Sep, 2016 3 commits
  13. 27 Sep, 2016 6 commits
  14. 26 Sep, 2016 1 commit
  15. 23 Sep, 2016 1 commit
    • Dean Moldovan's avatar
      Later assignments to accessors should not overwrite the original field · 2bab5793
      Dean Moldovan authored
      `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.
      2bab5793