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 whethersys.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 callsys.remote_exec().

Acceptedhttps://peps.python.org/pep-0768/ only addssys.remote_exec().

cc@pablogsal

Currently maybe the only test that really usessys.remote_exec is this interrupt one, but the whole remote pdb feature is built onsys.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 withsys.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 addingsys._remote_exec_supported() function.

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

int_PySysRemoteDebug_Supported(void){#if !defined(Py_SUPPORTS_REMOTE_DEBUG)return0;#elif !defined(Py_REMOTE_DEBUG)return0;#elsePyThreadState*tstate=_PyThreadState_GET();constPyConfig*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 addingsys._remote_exec_supported() function.

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

int_PySysRemoteDebug_Supported(void){#if !defined(Py_SUPPORTS_REMOTE_DEBUG)return0;#elif !defined(Py_REMOTE_DEBUG)return0;#elsePyThreadState*tstate=_PyThreadState_GET();constPyConfig*config=_PyInterpreterState_GetConfig(tstate->interp);return (config->remote_debug==1);#endif}

We already have it:

Ok, I rewrote my PR to usesys.is_remote_debug_enabled(). I chose to skip the only test which usessys.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 ifsys.remote_exec is not supported. It's pointless to test the mocking stuff. Also, wewill have other tests that requiressys.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 whenremote_exec() is not supported. Just raise aSkipTest at module level if it's not supported liketest_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.