-
Notifications
You must be signed in to change notification settings - Fork 6
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
Debug mode that can be easily activated without recompilation #36
Comments
What does "debug mode" mean to you? To me, it primarily means "turn on C asserts" which is not something that can be turned off without recompilation (or without a perf cost). |
Yes it means basically assertions. On top of traditional assertions I think the API should ideally have mechanisms that enforce parts of its contract that otherwise can get some leeway. For example, instead of handing out real pointers to internal data-structures, it would tag/untag them at the API boundary, which can be performance sensitive, so maybe not something to do in some production/release mode, but it would ensure that the user code cannot take advantage (*) of this implementation detail that is not part of the API contract.
Yes, not without a perf cost. I think that sometimes that could be justified (for extensions that are not performance sensitive or where hot code paths do not use Python API). Additionally, if there is some indirection already, like in HPy universal mode, where calls are routed via a pointer table, the additional cost is zero (we just use different pointer table, AFAIK modern CPUs should be good at predictable indirect jumps). Note that the HPy architecture also allows to compile in "CPython ABI" mode where this indirection is resolved at compile time and hence the turning on/off the debug mode at runtime does not work in this mode. I imagine that very performance sensitive extensions would chose to, for example, publish and maintain "CPython ABI" builds for the latest CPython version + HPy universal binary for all the other versions and other Python implementations. (*) My thinking: dereferencing a pointer and reading some data from it may seem ok-ish to some people that are not used to pay too much attention to "program against specification and not implementation", but hopefully untagging a pointer (if running in debug mode and not otherwise) should look fishy to anyone. |
I designed the Python Development Mode around the fact that many users don't have access to a debug build of Python. I would love that In 2022, I already proposed to remove assertions on Python release build, but the counter-argument is that (again) users don't have access to debug build. Thread: https://mail.python.org/archives/list/[email protected]/thread/RR3DJ4IZVSFKZUE5AV6OUCJ3QPYXD26Z/ It's inefficient that all users have to pay the cost of assertions at runtime when running correct C extensions. |
One possible option could be to enable users of GitHub Actions to use debug builds of Python as I would imagine that would enable a large percentage of open source projects to use debug builds for their test suite. I haven't checked how much work it would be to get debug interpreters available there, from a cursory glance there isn't a mention of I'd be willing to run a portion of PyO3's test suite against the debug interpreter, although I think I'd also want to run against the release interpreter (to verify compatibility, rather than speed, unless the debug interpreter is significantly slower). |
This seems a simple matter of elbow grease. Maybe just open issues in the various projects asking for this to be enabled, linking back here for reference? |
Like time that I checked, GHA didn't provide a debug build of Python. Did the situation change? |
There is an open issue in the setup-python github action to add debug builds: actions/setup-python#86. I commented there asking about the status of the issue. |
FWIW, NumPy does test a debug build using whatever apt install python3-dbg provides. |
As Victor Stinner already noted elsewhere people do not use debug builds and miss out on its features. One way to make people more likely to use debugging features (apart from more marketing) is if they did not require recompilation of (C)Python and ideally even recompilation of the extension, so that one could easily test the whole thing including 3rd party deps in debug mode.
The text was updated successfully, but these errors were encountered: