I don't think this is the correct way to fix it. If remote debugging is not supported, this whole test file should be skipped.

Do we have a flag somewhere about whether sys.remote_exec is supported? For now, we can do a quick test at the beginning of the module and skip the module if that's not supported.

I don't think this is the correct way to fix it. If remote debugging is not supported, this whole test file should be skipped.
Do we have a flag somewhere about whether sys.remote_exec is supported? For now, we can do a quick test at the beginning of the module and skip the module if that's not supported.

This change is a practical change for the current API. Currently, the only way to check if remote debugging is supported is to actually call sys.remote_exec().

Accepted https://peps.python.org/pep-0768/ only adds sys.remote_exec().

cc @pablogsal

Currently maybe the only test that really uses sys.remote_exec is this interrupt one, but the whole remote pdb feature is built on sys.remote_exec. Without it, it just won't work.

Having a specific check in _send_interrupt won't last once we add more tests (and we plan to do that very soon). We could run a quick foo test with sys.remote_exec() and test if this feature is supported, then skip the whole test if it's not. That could be a temporary solution before we have a flag to indicate whether it's supported.

There is a macro to detect if remote_exec is supported. We can expose the macro somewhere (either the sys module or some other place). Ideas?

Ah, I am forgetting I added this for this precise purpose:

>>> sys.is_remote_debug_enabled()
True

It needs #132959 first

There is a macro to detect if remote_exec is supported. We can expose the macro somewhere (either the sys module or some other place). Ideas?

If you dislike my approach, I suggest adding sys._remote_exec_supported() function.

Checking if it's supported is non-trivial. Pseudo-code:

int
_PySysRemoteDebug_Supported(void)
{
#if !defined(Py_SUPPORTS_REMOTE_DEBUG)
    return 0;
#elif !defined(Py_REMOTE_DEBUG)
    return 0;
#else
    PyThreadState *tstate = _PyThreadState_GET();
    const PyConfig *config = _PyInterpreterState_GetConfig(tstate->interp);
    return (config->remote_debug == 1);
#endif
}

There is a macro to detect if remote_exec is supported. We can expose the macro somewhere (either the sys module or some other place). Ideas?

If you dislike my approach, I suggest adding sys._remote_exec_supported() function.

Checking if it's supported is non-trivial. Pseudo-code:

int
_PySysRemoteDebug_Supported(void)
{
#if !defined(Py_SUPPORTS_REMOTE_DEBUG)
    return 0;
#elif !defined(Py_REMOTE_DEBUG)
    return 0;
#else
    PyThreadState *tstate = _PyThreadState_GET();
    const PyConfig *config = _PyInterpreterState_GetConfig(tstate->interp);
    return (config->remote_debug == 1);
#endif
}

We already have it:

Ok, I rewrote my PR to use sys.is_remote_debug_enabled(). I chose to skip the only test which uses sys.remote_exec(): test_keyboard_interrupt().

Example:

$ PYTHON_DISABLE_REMOTE_DEBUG=1 ./python -m test -v test_remote_pdb -m test_keyboard_interrupt
(...)
test_keyboard_interrupt (test.test_remote_pdb.PdbConnectTestCase.test_keyboard_interrupt)
Test that sending keyboard interrupt breaks into pdb. ... skipped 'remote debugging is disabled'
(...)

@gaogaotiantian: Please review the updated PR.

I still think we should skip the whole test file. Like I said, remote debugging does not exist if sys.remote_exec is not supported. It's pointless to test the mocking stuff. Also, we will have other tests that requires sys.remote_exec to execute - any integration test that actually attaches to the process (not just mock). I don't think we lose any coverage to simply skip this module when remote_exec() is not supported. Just raise a SkipTest at module level if it's not supported like test_pty.py.

I still think we should skip the whole test file.

Ok, I updated my PR to do that.

Sorry, I don't know this code, so I tried to write the smallest change :-)

Sorry, I don't know this code, so I tried to write the smallest change :-)

It makes sense to start with the smallest change :) In this specific case I think skipping the file is the way to go. This looks good.