Settings

Theme

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

github.com

22 points by markushirsimaki 2 months ago · 10 comments · 1 min read

Reader

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.

willquack 2 months ago

> `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!!!

malux85 2 months ago

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

  • banditelol 2 months ago

    Cool, can you share your setup for python and your current ide?

    • malux85 2 months ago

      Yes sure, dev containers inside each project, that way the entire environment (debugger, all ide plugins for linting etc) are standard across all devs and the coding environment matches prod exactly

      IDE is cursor

meken 2 months ago

I have a version of this, but it’s “open a Jupyter Notebook here” [1]. Though it’s not as polished as yours.

[1] https://github.com/ebanner/extipy

dkdcio 2 months ago

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

btreecat 2 months ago

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

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection