>> I.e.: something as adding a thread_id to sys.settrace -- sys.settrace(trace_func, thread_id=None).

> What is the use case for this feature?

The use case is having the user attach the debugger (either programmatically or by doing an attach to process) and be able to debug all threads, not just the current thread.

> It seems quite complicated to implement the thread_id for sys.settrace(trace_func, thread_id=None).

Humm, isn't it just a matter of passing the proper tstate to _PyEval_SetTrace? It seems reasonably simple to do at C (i.e.: iterate the existing thread states to get the thread id and then pass the proper tsate to _PyEval_SetTrace -- which is roughly what is done in the debugger, although it's a bit more complicated because it supports Python 2.7 up to Python 3.8...).

> At the C level, Python doesn't maintain a list of thread. There is only threading.enumerate() which is implemented in Python.

The tstate does contain the thread id, so, iterating the available tstates should be enough for that.

> PyDev.Debugger seems to use the C API. Can it continue to use the C API?

It can for CPython, but it can't for other Python implementations (and ideally I'd like to rely less on the CPython C-API -- because there's too much implementation details on it, things seem to break at each new version).

> Note: There is threading.setprofile() and threading.settrace() which set a profile/trace function when *new* threads are spawned

Yes, I know about those, but it's not enough if the user attaches the debugger after the process is already running.