Hm, this seems misleading -process is really a string that evaluates to aPopen or aProcess or a pid.

Probably should use the repr here, instead:

It might be worth considering accepting any object with apid attribute... that'd save you the imports ofmultiprocessing andsubprocess and would work onasyncio.subprocess.Process, too. And potentially processes from 3rd party libraries, too

It might be worth ensuring thatprocess.pid is an int (it might not be due to monkeypatching, for instance).

I'd suggest considering:

Probably worth adding a comment explaining what this message type is used for, if only for consistency with the other message types.

There are some assumptions inattach that the_PdbClient is being run from the main thread - the entire signal handling approach relies upon it, at the very least - I think it'll just wind up failing with an exception if run from a non-main thread, at the point where it tries to install the signal handler.

I think we should check if we're in the main thread explicitly andself.error() if not.

Or, thinking outside of the box, we could spawn a new process to do the attaching from its main thread, and return control back to the parent process after it finishes.

The great thing about attaching directly from the process is that there's the automatic parent-child relation. So even with the tracing restriction, you can still attach to your child processes - spawning a new process won't let you do that.

That's true, and that's a nice advantage - but certainly not one big enough to live with Ctrl+C not working! And you only get that advantage when starting off in non-remote PDB - if you started off in remote PDB, the child process won't be a child of the client (which means it also won't work when youattach to a child process and thenattach again to a grandchild process).

The most reasonable choice might just be to make it so that thepdb.attach module level function raises an exception if it's called from any thread but the main thread. Then theattach PDB command will work from any thread when running remote PDB, and from the main thread when running normal PDB, but will fail when when called on a non-main thread in non-remote PDB.

(which means it also won't work when you attach to a child process and then attach again to a grandchild process).

Is that true? I thought the trace_scope applies to descendants, not only direct children. So grandchildren should work? (I have a test that does that, if our linux buildbot has the restriction, it should prove the theory)

The most reasonable choice might just be to make it so that the pdb.attach module level function raises an exception if it's called from any thread but the main thread.

That seems a reasonable option. It won't work when_PdbClient is not in the main thread. We can explore other options in the future, but for now, making what works work seems to be the way to go.

(which means it also won't work when you attach to a child process and then attach again to a grandchild process).

Is that true? I thought the trace_scope applies to descendants, not only direct children. So grandchildren should work?

Ah, yes, you're right.