\

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

16 points - last Monday at 1:16 PM


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.

Source
  • 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!!!

      • skylurk

        yesterday at 4:36 AM

        Pdb also has !<cmd>

        For example, !interact will give you a working >>> REPL

        • BiteCode_dev

          today at 12:22 PM

          And ipdb if you want ipython repl.

      • meken

        today at 1:11 PM

        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

        • 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

                • banditelol

                  today at 12:31 PM

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

              • minihack

                today at 3:04 PM

                [dead]