On my Fedora system, test_gdb still fails when --without-doc-strings is configured, even after updating the decorator to cover both C and Python docstrings as an interim fix. That may be a real bug, though (see issue 19415 for details)

Regarding splitting the flags, I'm not sure I agree with RDM's reasoning in issue 17041. As soon as *any* docstrings are missing (whether it's C docstrings or Python docstrings), various parts of the introspection machinery are going to start behaving strangely.

By splitting the flags in the test suite, we're increasing the coupling between the tests and the implementation. For example, if something docstring dependent that was previously implemented in Python is moved to a C accelerator module, is it right for the test to have to know about that and switch to moving a different decorator?

In my view, "this is a C docstring" and "this is a Python docstring" is an implementation detail that the tests shouldn't have to care about. With the latest update, "test.supports.requires_docstrings" means "I require trustworthy docstrings, and if there's anything wrong with the docstring machinery, don't even try this test" without getting into the specifics of worrying about *why* the docstrings might be unreliable.