1. Dec 04, 2021
    • Ralf W. Grosse-Kunstleve's avatar
      1418c65d
    • Boris Rasin's avatar
      fix: vs2022 compilation, issue #3477 (#3497) · a224d0cc
      Boris Rasin authored
      
      
      * fix: vs2022 compilation, issue #3477
      
      * silence warning for python 2.7
      
      * disable warning around mbstowcs call
      
      * move disable warning code closer to call site
      
      * turn on vs2022 ci test
      
      * ci: don't run helpers on Windows 2022 & Python 3.5
      
      * limit workaround for stdlib shipped with vs2022 or later
      
      * fix for: limit workaround for stdlib shipped with vs2022 or later
      
      * fix 2 for: limit workaround for stdlib shipped with vs2022 or later
      
      * comment
      
      * ci: add a Windows 2019 run
      
      * ci: add Python 2.7 check too
      
      Co-authored-by: default avatarHenry Schreiner <HenrySchreinerIII@gmail.com>
      a224d0cc
    • Ralf W. Grosse-Kunstleve's avatar
      d13e03af
    • 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
  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