[HN Gopher] Checking Out CPython 3.14's remote debugging protocol
___________________________________________________________________
Checking Out CPython 3.14's remote debugging protocol
Author : ingve
Score : 73 points
Date : 2025-07-23 09:57 UTC (13 hours ago)
(HTM) web link (rtpg.co)
(TXT) w3m dump (rtpg.co)
| BossingAround wrote:
| So, IIUIC, new capabilities:
|
| - It'll be possible to print stack traces without modifying or
| stopping the program.
|
| - It'll be possible to exec into a program at runtime without
| modifying it.
|
| I'm not sure why the author mentions remote_pdb - this has been
| with Python for some time, and works since Py 2.7? Not sure what
| changes in 3.14 for remote_pdb.
|
| 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.
|
| I would love to use something like Zed, but without remote
| debugging abilities, the IDE is pretty useless for me. Perhaps
| better devs don't need remote debugging, but I depend on it more
| than a junior in college CS program depends on AI :)
| jasonjmcghee wrote:
| 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.
| maeln wrote:
| If I understand correctly, this would be very useful to debug
| application running on GUnicorn, Celery, etc. Apps that usually
| have several workers / processes / threads. Currently, it is very
| annoying to use pdb for that. The Debug Adapter Protocol works
| well for this case, but the only fully feature, and not buggy,
| client right now is VSCode (last I checked, the nvim
| implementation was still a bit buggy. Didn't try the Emacs one).
|
| I really like debugging in a simple shell (a la gdb) so this
| would really be nice for my workflow.
| BossingAround wrote:
| 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?
| maeln wrote:
| yes debugpy is the implementation of dap for python
| frou_dh wrote:
| Seems pretty nice. I was getting worried when it was talking
| about requiring a third-party library (remote_pdb), but at least
| it sounds like you can now attach pdb to any running process on
| the same box using OOTB tooling only.
| poulpy123 wrote:
| I don't know if it's possible byt I would love to have a debugger
| that allows to go back in time from a breakpoint or an exception
| dripton wrote:
| Yes, the term you're looking for is "reverse debugging". It
| exists, and it's better.
| jasonjmcghee wrote:
| The popular (Linux only) solution is https://rr-project.org/
| jasonjmcghee wrote:
| I found this to be a very good official resource on the topic
| https://peps.python.org/pep-0768/
| whinvik wrote:
| Just to clarify, this requires both the client and the debugging
| script to be running 3.14? So I cannot have a script running an
| older version of Python but use a Python 3.14 debug script to
| attach to the running script?
| joshlk wrote:
| Yes
| skeledrew wrote:
| Wow, this pops up only a few days after I discover the existence
| of pyrasite[0]. I even created a wrapper around it to get a
| decent REPL (using ptpython[1]) and am planning to extend it over
| time into a kind of Pharo/Smalltalk live coding experience.
|
| [0] https://pyrasite.readthedocs.io/en/latest/ [1]
| https://github.com/prompt-toolkit/ptpython
| sczi wrote:
| 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/
| orbisvicis wrote:
| The problem is running the injected code at a specific
| location... line number or definition.
___________________________________________________________________
(page generated 2025-07-23 23:01 UTC)