Checking Out CPython 3.14's remote debugging protocol

> What I'm hoping though is improved tooling around debugging Python. Currently, in my experience, VSCode (more specifically, debugpy) provides pretty much unmatched remote debugging capabilities, and I'm really hoping we can have a standardized way to connect any IDE to remote Python processes with the same UX as VSCode.

This is what 3.14's remote debugging protocol gives us. And even more than that, because I believe that debugpy needs to be invoked beforehand!

The value of this tooling is you don't need to predict that you need debugging before running the program. All of your Python programs[0] can be debugged. No need to restart. No need to modify the launch parameters either: you don't need the "debug configuration" from vscode, you just need a PID.

[0]: so long as you're using the same version of Python and it has the remote debugging protocol enabled, and also you have the right OS permissions

I thought the author mentioned remote pdb because it sounds like you can use it to attach to cpython now, and previously gdb would have been needed? I'm at last a few years behind on debugging cpython... But always used gdb.

When debugging multi-threaded env with debugpy & VSCode, VSCode jumps to code that is active in currently active thread. Is DAP something different? From briefly looking at the docs, it seems like DAP calls debugpy for Python debugging, so we're probably talking about the same experience?

Yeah I think pyrasite would be able to vastly simplify its implementation if it chose to (it might not though! the "same python version" requirements can feel strict)

Interesting, I hadn't heard of pyrasite, it has a nice GUI with info about objects' memory usage, threads, open files and more. I'll definitely take ideas from it.

I'm working on a live coding environment for python[0], based on emacs' SLIME mode for common lisp. It's quite new and I haven't written documentation yet, but all the main SLIME features not covered by LSP are working.

- All results printed in the repl are presentations that can be inspected, copied around and used again -- as the actual object, not just it's str or repr text like in most repls.

- On any uncaught exception you get an interactive backtrace buffer where you can jump to source, see arguments and local variables for each frame, and eval code or open a repl in the context of any stack frame. And the arguments and local variables aren't just text but presentations you can open in the object inspector, copy to the repl and use, etc.

- A thread viewer where you can view stats on all threads, get the backtrace of any thread, spawn a repl in the context of any of it's stack frames, etc.

- An async task viewer with somewhat more limited functionality as async tasks don't keep a full stack.

- A pretty documentation browser using mmontone's slime-doc-contribs.

- The ability to trace functions, where again their arguments and return values aren't just printed as text, but as presentations, that you can open in the inspector, copy to the repl, etc.

- I took some code from IPython's autoreload extension, so interactive development without restarting and losing state mostly works.

If you want to collaborate or just talk ideas that'd be fantastic, I don't have any experience with the Pharo/Smalltalk world.

https://codeberg.org/sczi/swanky-python/

Yes, the term you're looking for is "reverse debugging". It exists, and it's better.

The popular (Linux only) solution is https://rr-project.org/

You can presumably run code that calls `sys.settrace` for that. Which makes it somewhat underwhelming to realize that you pretty much could also do that before, but perhaps convenient that now you don't have to have the foresight to have set that up beforehand.

So Python 3.14 introduces this functionality. The process you want to debug needs to be on at least Python 3.14.

If you want to "just" use sys.remote_exec, you will need to use that from a matching Python version. If you dive into the implementation (check out the PEP), you could most definitely write a C or Rust program that implements remote_exec and "does the thing".

The protocol is basically "tell the program to read a python script from this file". That python script will be executed in the running program's environment, but you don't need for the software on the other side to be a python program!

sys.remote_exec itself only targets same Python versions though.

Yes