1. Dec 04, 2021
    • Jason Rhinelander's avatar
      Expand std::string_view support to str, bytes, memoryview (#3521) · b4939fcb
      Jason Rhinelander authored
      * Expand string_view support to str, bytes, memoryview
      
      1. Allows constructing a str or bytes implicitly from a string_view;
         this is essentially a small shortcut allowing a caller to write
         `py::bytes{sv}` rather than `py::bytes{sv.data(), sv.size()}`.
      
      2. Allows implicit conversion *to* string_view from py::bytes -- this
         saves a fair bit more as currently there is no simple way to get such
         a view of the bytes without copying it (or resorting to Python API
         calls).
      
         (This is not done for `str` because when the str contains unicode we
         have to allocate to a temporary and so there might not be some string
         data we can properly view without owning.)
      
      3. Allows `memoryview::from_memory` to accept a string_view.  As with
         the other from_memory calls, it's entirely your responsibility to
         keep it alive.
      
      This also required moving the string_view availability detection into
      detail/common.h because this PR needs it in pytypes.h, which is higher
      up the include chain than cast.h where it was being detected currently.
      
      * Move string_view include to pytypes.h
      
      * CI-testing a fix for the "ambiguous conversion" issue.
      
      This change is known to fix the `tensorflow::tstring` issue reported under https://github.com/pybind/pybind11/pull/3521#issuecomment-985100965
      
      
      
      TODO: Minimal reproducer for the `tensorflow::tstring` issue.
      
      * Make clang-tidy happy (hopefully).
      
      * Adding minimal reproducer for the `tensorflow::tstring` issue.
      
      Error without the enable_if trick:
      
      ```
      /usr/local/google/home/rwgk/forked/pybind11/tests/test_builtin_casters.cpp:169:16: error: ambiguous conversion for functional-style cast from 'TypeWithBothOperatorStringAndStringView' to 'py::bytes'
              return py::bytes(TypeWithBothOperatorStringAndStringView());
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/local/google/home/rwgk/forked/pybind11/include/pybind11/detail/../pytypes.h:1174:5: note: candidate constructor
          bytes(const std::string &s) : bytes(s.data(), s.size()) { }
          ^
      /usr/local/google/home/rwgk/forked/pybind11/include/pybind11/detail/../pytypes.h:1191:5: note: candidate constructor
          bytes(std::string_view s) : bytes(s.data(), s.size()) { }
          ^
      ```
      
      * Adding missing NOLINTNEXTLINE
      
      * Also apply ambiguous conversion workaround to str()
      
      Co-authored-by: default avatarRalf W. Grosse-Kunstleve <rwgk@google.com>
      b4939fcb
  2. Dec 03, 2021
  3. Nov 23, 2021
  4. Nov 22, 2021
  5. Nov 21, 2021
    • Jason Rhinelander's avatar
      Fix py::kw_only when used before the first arg of a method (#3488) · 673b4be3
      Jason Rhinelander authored
      * Fix py::kw_only when used before the first arg of a method
      
      The implicit space for the `self` argument isn't added until we hit the
      first argument, but this wasn't being done for kw_only or pos_only, and
      so a kw_only before the first argument would break.
      
      This fixes it by properly checking whether we need to add the self arg.
      
      (The pos_only issue here was extremely mild -- you didn't get the `/` in
      the docstring, but AFAICT it has no other effect since there are no
      meaningful arguments before it anyway).
      
      * Style changes
      
      - rename check_have_self_arg -> append_self_arg_if_needed
      
      - move the argument name inline comments before the args instead of
        after
      673b4be3
  6. Nov 19, 2021
  7. Nov 18, 2021
  8. Nov 17, 2021
  9. Nov 16, 2021
  10. Nov 14, 2021
  11. Nov 12, 2021
  12. Nov 11, 2021
  13. Nov 09, 2021
  14. Nov 08, 2021
  15. Nov 06, 2021
  16. Nov 02, 2021
  17. Oct 29, 2021
    • Jason Rhinelander's avatar
      feat: allow kw-only args after a py::args (#3402) · e7c9753f
      Jason Rhinelander authored
      
      
      * Simply has_kw_only_args handling
      
      This simplifies tracking the number of kw-only args by instead tracking
      the number of positional arguments (which is really what we care about
      everywhere this is used).
      
      * Allow keyword-only arguments to follow py::args
      
      This removes the constraint that py::args has to be last (or
      second-last, with py::kwargs) and instead makes py::args imply
      py::kw_only for any remaining arguments, allowing you to bind a function
      that works the same way as a Python function such as:
      
          def f(a, *args, b):
              return a * b + sum(args)
      
          f(10, 1, 2, 3, b=20)  # == 206
      
      With this change, you can bind such a function using:
      
          m.def("f", [](int a, py::args args, int b) { /* ... */ },
              "a"_a, "b"_a);
      
      Or, to be more explicit about the keyword-only arguments:
      
          m.def("g", [](int a, py::args args, int b) { /* ... */ },
              "a"_a, py::kw_only{}, "b"_a);
      
      (The only difference between the two is that the latter will fail at
      binding time if the `kw_only{}` doesn't match the `py::args` position).
      
      This doesn't affect backwards compatibility at all because, currently,
      you can't have a py::args anywhere except the end/2nd-last.
      
      * Take args/kwargs by const lvalue ref
      
      Co-authored-by: default avatarHenry Schreiner <HenrySchreinerIII@gmail.com>
      
      Co-authored-by: default avatarHenry Schreiner <HenrySchreinerIII@gmail.com>
      e7c9753f
  18. Oct 28, 2021
  19. Oct 27, 2021
    • Henry Schreiner's avatar
      fix: improve support for Python 3.11-dev (#3368) · e7e2c79f
      Henry Schreiner authored
      * ci: support Python 3.11-dev
      
      Also update 3.10 to final, better PyPy usage
      
      * fix: use PyFrame_GetCode on Python 3.9+
      
      * ci: some bitiness of pypy not supported on win
      
      * chore: update CMake support to 3.22rc1 to quiet warning
      
      * fix: use dev version of py to fix Py 3.11
      
      * tests: print proper Eigen version
      
      * ci: include pypy2, not sure why
      
      * ci: avoid running on Python 3.11 for now
      
      * ci: fix runs
      
      * ci: simpler PyPy usage, drop unmaintained scipy + pypy index
      
      * ci: only binary numpy, wait on pypy 3.8
      
      * refactor: address review
      e7e2c79f
  20. Oct 26, 2021
    • Ryan Cahoon's avatar
      fix: the types for return_value_policy_override in optional_caster (#3376) · c2d3e220
      Ryan Cahoon authored
      
      
      * fix: the types for return_value_policy_override in optional_caster
      
      `return_value_policy_override` was not being applied correctly in
      `optional_caster` in two ways:
      - The `is_lvalue_reference` condition referenced `T`, which was the
      `optional<T>` type parameter from the class, when it should have used `T_`,
      which was the parameter to the `cast` function. `T_` can potentially be a
      reference type, but `T` will never be.
      - The type parameter passed to `return_value_policy_override` should be
      `T::value_type`, not `T`. This matches the way that the other STL container
      type casters work.
      
      The result of these issues was that a method/property definition which used a
      `reference` or `reference_internal` return value policy would create a Python
      value that's bound by reference to a temporary C++ object, resulting in
      undefined behavior. For reasons that I was not able to figure out fully, it
      seems like this causes problems when using old versions of `boost::optional`,
      but not with recent versions of `boost::optional` or the `libstdc++`
      implementation of `std::optional`. The issue (that the override to
      `return_value_policy::move` is never being applied) is present for all
      implementations, it just seems like that somehow doesn't result in problems for
      the some implementation of `optional`. This change includes a regression type
      with a custom optional-like type which was able to reproduce the issue.
      
      Part of the issue with using the wrong types may have stemmed from the type
      variables `T` and `T_` having very similar names. This also changes the type
      variables in `optional_caster` to use slightly more descriptive names, which
      also more closely follow the naming convention used by the other STL casters.
      
      Fixes #3330
      
      * Fix clang-tidy complaints
      
      * Add missing NOLINT
      
      * Apply a couple more fixes
      
      * fix: support GCC 4.8
      
      * tests: avoid warning about unknown compiler for compilers missing C++17
      
      * Remove unneeded test module attribute
      
      * Change test enum to have more unique int values
      
      Co-authored-by: default avatarAaron Gokaslan <skylion.aaron@gmail.com>
      Co-authored-by: default avatarHenry Schreiner <HenrySchreinerIII@gmail.com>
      c2d3e220
    • pre-commit-ci[bot]'s avatar
      d45a8810
    • Henry Schreiner's avatar
      fix: MSVC 2017 C++17 on Python 3 regression (#3407) · 9379b399
      Henry Schreiner authored
      * fix: MSVC 2017 C++17 on Python 3 regression
      
      * ci: add 3.7 job on CI
      9379b399
  21. Oct 23, 2021
  22. Oct 21, 2021
  23. Oct 20, 2021
  24. Oct 18, 2021