logoalt Hacker News

Show HN: Seapie – a Python debugger where breakpoints drop into a REPL

11 points • by markushirsimaki • last Monday at 1:16 PM • 7 comments • view on HN

Author here.

I started seapie as a reaction to pdb's command-driven interface in 2019. I wanted a breakpoint to simply mean 'open a Python REPL here', with debugging functionality layered on top instead of replacing the REPL.

`seapie.breakpoint()` opens a working `>>>` REPL at the current execution state. Any changes to variables or function definitions persist. Debugger state is exposed via built-ins (e.g. `_magic_`), and stepping/frame control/etc is handled via small `!commands`.

I've been using this regularly in my own work for a few years now. Happy to answer questions or hear criticism, especially from people who've used debuggers heavily.

Comments

willquack • last Monday at 9:31 PM

> `seapie.breakpoint()` opens a working `>>>` REPL at the current execution state. Any changes to variables or function definitions persist. Debugger state is exposed via built-ins (e.g. `_magic_`), and stepping/frame control/etc is handled via small `!commands`.

This is largely what `pdb` does already, no? Example:

```

(Pdb) list

  1   something = 100

  2   import pdb; pdb.set_trace()

  3  -> print(f"value is: {something}")
(Pdb) something = 1234

(Pdb) c

value is: 1234

```

I do like that you use `!<cmd>` to avoid the naming collision issue in pdb between commands and python code!!!

➕ show 2 replies
btreecat • today at 12:35 PM

How does this compare to pudb? That has a nice TUI and drops you into one of several Python REPL you can choose from.

dkdcio • today at 12:01 PM

you can set breakpoint() to open an IPython REPL with whatever customizations you want (e.g. I turn on vim keybindings)

malux85 • last Monday at 9:24 PM

I use debuggers heavily, I code like Carmack does - I basically live in the debugger. The REPL at breakpoints is already integrated into my IDEs (all of the different ones) for the last 20 years, I couldn’t imagine a debugger without this functionality.

I guess this could be useful if you were cli only and didn’t use an IDE, but it’s not just the REPL that I like, in my IDE when I hit a breakpoint, I can see all local variables, the whole call stack without having to do anything (don’t have to type commands, don’t have to click buttons) - I want to see the entire program state without having to type a bunch of stuff at a REPL, that would slow me down enormously.

For example in the gif when you hit a breakpoint, print the line straight away! Don’t make me type: print(__line__, __source__) just to see which breakpoint I hit (!)

Also I preview of the variables would be better, in my ide I see a list if all the local variables and all of their values (str, int, float, are just shown, numpy arrays the shape is shown, arrays the first few values are shown and the length) again, all of this without having to type exhaustive print statements into a REPL

Maybe it’s not your focus though, I’m just trying to say what I love about debugger driven development

➕ show 1 reply