Uh oh!
There was an error while loading. Please reload this page.
Docs: Update py::kwargs example in function.rst to pass by reference - #3038
Conversation
rwgk
commented
Jun 17, 2021
The Centos 8 failure is unrelated (it appeared ~June 4; we're working on it). |
rwgk
commented
Jun 17, 2021
Thanks for this change! I really like your clang-tidy suggestion, but unless we find a volunteer to add this to the GitHub Actions it's very unlikely to happen. |
Skylion007
commented
Jun 17, 2021
@rwgk Happy to do it, but the only way I know how to do to it properly is to have a hierarchical config (since we don't want it making changes to the obvious copies and movies that we do in the tests folder). These would require a new version of Clang-Tidy (>12) and the github action only uses clang-tidy 10. Happy to set this up if you don't mind bumping the clang-tidy version: https://reviews.llvm.org/D75184 |
rwgk
commented
Jun 17, 2021
I'm up for trying, assuming we can roll back to 10 if trying 12 gets us into trouble. I'm not very familiar with the GitHub Action tooling. Is bumping the clang-tidy version just another PR? In that case I'd say let's just try and make decisions based on the outcome. |
Skylion007
commented
Jun 17, 2021
henryiii
commented
Jun 17, 2021
Sure, feel free to bump pybind11/.github/workflows/format.yml Line 30 in b4b67f0 |
Description
A very common clang-tidy performance issue I have noticed is that py::dict is not trivially copyable, but I can't think of any case where where you want to actually create a shallow copy of the dict intentionally. Furthermore, not creating a shallow-copy of the dict would better match pythonic syntax in the C++ side. As such, I propose editing the documentation to have this be the default practice. There are probably a lot more areas where this could be improved, but here are the two most common pieces of code I see being copy and pasted around.
As an aside, I'd recommend enabling the clang-tidy performance checks at some point to catch these issues in the tests and other places. Not that they are performance sensitive per say, but that they should show best coding practices.
Suggested changelog entry: