Repository navigation
cuda.core: replace bare assert statements in library code with explicit errors #3202
Description
Follow-up to #2697, where @mdboom asked for all assert statements to leave the library (tests keep theirs), and @fedonman offered to convert them. #2704 handles the two in _memory/_ipc.pyx. This issue is the rest.
The inventory from #2697 (comment) still matches main (checked 2026-10-23): 15 remain, in _program.pyx, _module.pyx, _memoryview.pyx (five), _device.pyx, _memory/_managed_buffer.py, _memory/_managed_memory_resource.pyx, system/_device.pyx, system/_system_events.pyx, system/_field_values.pxi, and utils/_program_cache/ (two).
Conversion rules, from cuda_core/CLAUDE.md ("Failure handling"):
- A check on a value that comes from outside (an argument, a producer's protocol answer, an NVML payload) raises
ValueErrororTypeErrorwith a message that names the value. - An internal invariant raises
RuntimeError("internal cuda.core error, please report: <what failed>"). assert Falseon an unreachable branch becomes the sameRuntimeError.- Cython
assertstatements go too: Cython also drops them under-O.
To keep them out, enable ruff's S101 for library code: remove it from the global ignore list in ruff.toml and ignore it for **/tests/** only. The test suite keeps its asserts.
One PR after #2704 merges, so the two do not conflict. @fedonman, the offer in #2697 stands if you want it; say so here and I assign the issue to you.
Activity
fedonman commentedon Oct 26, 2026
Yes, I'd like to take it. #3223 is up. It doesn't touch any file that #2704 does, so it shouldn't need to wait for it.
leofang commentedon Oct 28, 2026
@mdboom what is the reason that we don't like Python
assertin cuda-core?mdboom commentedon Oct 28, 2026
asserts in Python are tricky because the user can turn them off at any time by starting the Python interpreter with-O. As #2697 indicated, that causes behavioral differences and things breaking in strange ways for our users. This is different from C/C++ (which also turns off asserts based on config) because that requires a rebuild -- it's common practice for a debug and release build that may have different behavior -- our (and most) Python extensions don't work that way.ruff, for example flags all uses of assert by default.cython-lintdoesn't have this check, unfortunately.It's perfectly fine to want to assert things that we don't want to have an impact on runtime, but those should be put in unit tests, not inline in the library code. If that makes it hard to insert exactly where we need, monkeypatching or refactoring the code is often a reasonable way forward.