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
Disable runtime checks in release mode #81587
Comments
A Python debug build is ABI compatible with a Python release build since Python 3.8 on most platforms (except Windows, Cygwin and Android): It should now be way easier to debug an application with a debug build. I propose to remove runtime debug checks in release mode. assert() is already widely used in the C code base, but there are many runtime checks using PyErr_BadInternalCall() or PyErr_BadArgument. Example: Py_ssize_t
PyUnicode_GetLength(PyObject *unicode)
{
if (!PyUnicode_Check(unicode)) {
PyErr_BadArgument();
return -1;
}
if (PyUnicode_READY(unicode) == -1)
return -1;
return PyUnicode_GET_LENGTH(unicode);
} Attached PR removes these checks when Python is compiled in release mode: when Py_DEBUG is not defined. Even if I marked this issue as "performance", I don't expect a significant speedup. |
Given that extensions call these APIs, I find it highly risky to Using assert() in C is a pretty bad alternative, since this crashes -- Professional Python Services directly from the Experts (#1, Jun 26 2019)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> Python Database Interfaces ... http://products.egenix.com/
>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 |
I think that the public C API should have runtime checks for its arguments, except performance sensitive functions and macros (like PyTuple_GET_ITEM). The internal C API can use just asserts. I have a work-in-progress patch which adds tests for the public C API, including calls with invalid arguments. |
I disagree. There is a difference between exceptions which are possible in normal usage of the code and real bugs, which shouldn't ever happen. A NULL argument to a C API function is not an ordinary exception, it's a real bug. Even if we raise a Python exception for that, it should never be handled in a try/exception block like an ordinary exception.
I *prefer* debugging an assert() failure (which is pretty easy with a decent debugger) rather than debugging a Python exception raised from C (which typically does NOT give a useful traceback). |
FYI I'm finishing an article to explain the problem that I am trying to solve here. Sorry for the delay, I will reply later :-) |
I didn't find time to write a proper a rationale for this change, and I will not be available next weeks. So I prefer to close this issue. I may reopen it later once I have a strong rationale :-) In the meanwhile, have a look at the new PyHandle API idea which will start without sanity check in release mode since day 1 :-) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: