-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace error printing code gated by NDEBUG with a new flag: PYBIND11_DETAILED_ERROR_MESSAGES #3913
Conversation
Apologies upfront if this is not desired. I am not 100% sure how to test it, I did run all unit tests and nothing exploded. |
for more information, see https://pre-commit.ci
@Skylion007 Thanks for the stamp, I do not have write access :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general idea is great, but the implementation needs more attention.
The prefix for macros is universally PYBIND11_
(11
is currently missing).
LOG
isn't very fitting, let's think carefully about naming. I think ERROR
definitely needs to be in the name, maybe PYBIND11_DETAILED_ERROR_MESSAGES
?
"compile in" appears in these files:
cast.h
attr.h
pybind11.h
detail/type_caster_base.h
After a quick pass looking at those files, I'm thinking it is best to replace NDEBUG
with the new macro for all "compile in" matches. With that comes the idea to handle the definition of the new macro in detail/common.h.
The old phrase "compile in debug mode for ..." is best updated, e.g. "compile with PYBIND11_DETAILED_ERROR_MESSAGES defined for ..." will be more to the point and helpful.
The current #if
logic definitely needs work:
#if !defined(PYBIND11_DETAILED_ERROR_MESSAGES) && !defined(NDEBUG)
# define PYBIND11_DETAILED_ERROR_MESSAGES
#endif
Optional, or follow-on PR: define the macro for at least one non-debug CI job (very easy) and verify that some error is complete with details (needs some thought, unless someone already has a good idea how to implement that).
Great suggestions, one and all. I’ll get to this tonight. Cheers.
…On Thu, Apr 28, 2022 at 11:31 PM Ralf W. Grosse-Kunstleve < ***@***.***> wrote:
***@***.**** requested changes on this pull request.
The general idea is great, but the implementation needs more attention.
The prefix for macros is universally PYBIND11_ (11 is currently missing).
LOG isn't very fitting, let's think carefully about naming. I think ERROR
definitely needs to be in the name, maybe PYBIND11_DETAILED_ERROR_MESSAGES
?
"compile in" appears in these files:
cast.h
attr.h
pybind11.h
detail/type_caster_base.h
After a quick pass looking at those files, I'm thinking it is best to
replace NDEBUG with the new macro for all "compile in" matches. With that
comes the idea to handle the definition of the new macro in detail/common.h.
The old phrase "compile in debug mode for ..." is best updated, e.g.
"compile with PYBIND11_DETAILED_ERROR_MESSAGES defined for ..." will be
more to the point and helpful.
The current #if logic definitely needs work:
#if !defined(PYBIND11_DETAILED_ERROR_MESSAGES) && !defined(NDEBUG)
# define PYBIND11_DETAILED_ERROR_MESSAGES
#endif
Optional, or follow-on PR: define the macro for at least one non-debug CI
job (very easy) and verify that some error is complete with details (needs
some thought, unless someone already has a good idea how to implement that).
—
Reply to this email directly, view it on GitHub
<#3913 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEI6NCNF5EEPIPYA35ZB2LVHN65XANCNFSM5UT72ZWA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
@rwgk thanks for the great feedback. Applied. w/r/t
There are tests in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me!
@Skylion007, do you want to take another look?
Description
Does what it says in the title. We have some internal use cases of pybind where we would love to get richer logging from within pybind, but are not running a debug build.
Suggested changelog entry: