cansarigol/pdbr

pdb + Rich library

pdbr's Issues

Incomplete code in traceback

Hi, the library show's incomplete code when the breakpoint is set as shown in the figure.

Im using -
Python 3.7.10
Development environment - Mac OS Catalina 10.15.7

No code snippet highliting (ipdb does it)

As seen in screenshot below, the code snippets are not colored in any way, I would have expected at least the filename to be colored. At the same time ipdb does it.

I know that pdbr prints better variables, but if the cost of doing this means losing the trace highlighting, I kinda doubt people will still to it.

Feature request: Add guide to install `pdbr` to `sys.excepthook`.

incompatible with rich 13.0

Having a ceiled version in requirements makes this act like a time-bomb. Please consider removing it.

For the time being I will stuck to ipdb.

pdbr vs ipdb

Are there any features missing from ipdb? This seems like a full replacement for ipdb (which is awesome). If that's the case, hopefully we can get the ipython documentation updated to include this package as an alternative.

Error when using post_mortem

the code:

import pdbr
import sys
try:
    1/0
except Exception:
    pdbr.post_mortem(sys.exc_info()[2])

raises the error:

Traceback (most recent call last):
  File "D:/Program Data/Pycharm/PycharmProjects/python_tell/ttt.py", line 8, in <module>
    1/0
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:/Program Data/Pycharm/PycharmProjects/python_tell/ttt.py", line 10, in <module>
    pdbr.post_mortem(sys.exc_info()[2])
  File "D:\Program Data\Pycharm\PycharmProjects\python_tell\venv\lib\site-packages\pdbr\__main__.py", line 22, in post_mortem
    pdbr_cls().post_mortem(t)
  File "D:\Program Data\Pycharm\PycharmProjects\python_tell\venv\lib\site-packages\pdbr\utils.py", line 70, in pdbr_cls
    return klass()
  File "D:\Program Data\Pycharm\PycharmProjects\python_tell\venv\lib\site-packages\pdbr\_pdbr.py", line 55, in __init__
    super().__init__(**init_kwargs)
  File "D:\Program Data\Pycharm\PycharmProjects\python_tell\venv\lib\site-packages\IPython\terminal\debugger.py", line 32, in __init__
    self.pt_init(pt_session_options)
  File "D:\Program Data\Pycharm\PycharmProjects\python_tell\venv\lib\site-packages\IPython\terminal\debugger.py", line 74, in pt_init
    style=self.shell.style,
AttributeError: 'TerminalInteractiveShell' object has no attribute 'style'

Updating rich dependency to include 12.x

Thanks for creating pdbr, I just discovered it and it looks amazing! It seems more feature-rich for my debugging workflow than e.g. pdbpp which I've been using until now.

Would it be possible to update the dependencies to support rich 12.x?
Our app currently uses rich 12.x and so we can't add pdbrr as a dev dependency as it strictly requires 10.x.

I've got a workaround by installing pdbrr globally and then using virtualenv .venv --system-site-packages to create a virtualenv for our app that also includes pdbrr, but that's definitely fragile.

It looks like this line needs a bump, but I'm not sure if there's other places that require changes:

pdbr/pyproject.toml

Line 26 in 7cbe961

rich = "^10.0.0"

Thanks!

pyreadline error on ptipython

environment

• Python 3.9.5
• IPython 7.23.1
• ptipython 3.0.16
• Ubuntu 21.04
• Python 3.9.5

Steps to reproduce

• run ptipython
• run import pdbr

error log

Heading

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-3-30ffa7b6f6f3> in <module>
----> 1 import pdbr

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/pdbr/__init__.py in <module>
----> 1 from pdbr.__main__ import RichPdb, celery_set_trace, pm, post_mortem, run, set_trace
      2 from pdbr._cm import apdbr_context, pdbr_context
      3
      4 __all__ = [
      5     "set_trace",

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/pdbr/__main__.py in <module>
      3 import sys
      4
----> 5 from .utils import _pdbr_cls, _rdbr_cls
      6
      7 os.environ["PYTHONBREAKPOINT"] = "pdbr.set_trace"

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/pdbr/utils.py in <module>
      6
      7 try:
----> 8     import readline
      9 except ImportError:
     10     from pyreadline import Readline

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/readline.py in <module>
      4 #of a readline module
      5 from __future__ import print_function, unicode_literals, absolute_import
----> 6 from pyreadline.rlmain import Readline
      7
      8 __all__ = [ 'parse_and_bind',

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/pyreadline/__init__.py in <module>
     10
     11 from . import unicode_helper
---> 12 from . import logger, clipboard, lineeditor, modes, console
     13 from . rlmain import *
     14 from . import rlmain

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/pyreadline/clipboard/__init__.py in <module>
     11 else:
     12     try:
---> 13         from .win32_clipboard import GetClipboardText, SetClipboardText
     14     except ImportError:
     15         from .no_clipboard import GetClipboardText, SetClipboardText

~/.pyenv/versions/3.9.5/envs/scripts/lib/python3.9/site-packages/pyreadline/clipboard/win32_clipboard.py in <module>
     40 from pyreadline.unicode_helper import ensure_unicode,ensure_str
     41
---> 42 OpenClipboard = windll.user32.OpenClipboard
     43 OpenClipboard.argtypes = [wintypes.HWND]
     44 OpenClipboard.restype = wintypes.BOOL

NameError: name 'windll' is not defined

note

i recommend either exclude pyreadline for non windows user or use alternative because pyreadline last release is Sep 16, 2015

related

• pyreadline/pyreadline#58

support set break point from CLI parameters.

ipdb can be used like this:

ipdb -c 'b wantToBreakInFile:100' launcher.py

So Should we pass the parameter "-c" to pdb ?

add prompt_toolkit to dependencies

prompt_toolkit was not added to dependencies in pyproject (imported in this line)

to your pyproject.toml
so when importing pdbr it raise:

ModuleNotFoundError: No module named 'prompt_toolkit'

Colorizing special objects whose repr contains `[` (example: `torch.Tensor` or `np.ndarray`)

Thanks for the amazing work! I loved pdbr at the first sight!🥰
However, there's one small caveat:
The color is lost when printing special objects whose repr contains a [ character.

Upon deeper inspection, I found that the _print method of RichPdb will try to render the markup color of the string if a [ is present. This would result in torch.Tensor and np.ndarray or any objects whose string representation contains a [ having no color.

pdbr/pdbr/_pdbr.py

Line 399 in 86dc66c

if isinstance(val, str) and "[" in val:

pdbr/pdbr/_pdbr.py

Lines 395 to 411 in 86dc66c

	def _print(self, val, prefix=None, style=None, print_layout=True):
	if val == "--Return--":
	return
	if isinstance(val, str) and "[" in val:
	val = markup.render(val)
	kwargs = {"style": str(style)} if style else {}
	args = (prefix, val) if prefix else (val,)
	if (
	show_layouts
	and print_layout
	and self.lastcmd not in WITHOUT_LAYOUT_COMMANDS
	):
	self._print_layout(*args, **kwargs)
	else:
	self.console.print(*args, **kwargs)

Example:

Here we can successfully print a torch.Tensor with color using a plain console.print, while the color is lost when directly submitting the variable through pdbr. Printing numbers or strings is OK.


Printing the rendered "markup" using console.print leads to the same result as submitting the variable directly.

Is it possible to expose an option in pdbr to disable or enable the handling of markup texts? After all, it's quite often for a lot of users to inspect a torch.Tensor or numpy array. Or do you have other suggestions on how I could print these variables directly in the debugger prompt with color? 🥰Thanks!

setup.cfg file path

Hi,

Would you be open to add an environment variable to point towards which file should be use for pdbr config, since now it looks like that the invocation must be made in the same folder where setup.cfg resides, or is there another way to do it?

Perhaps also, it could look in $XDG_CONFIG_HOME/pdbr/pdbr.cfg.

I can take care of it if you will accept the PR.

Thanks.

Fix windows test errors

https://github.com/cansarigol/pdbr/runs/5351140347?check_suite_focus=true

____________________ ERROR collecting tests/test_magic.py _____________________
ImportError while importing test module 'D:\a\pdbr\pdbr\tests\test_magic.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
c:\hostedtoolcache\windows\python\3.7.9\x64\lib\importlib\__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests\test_magic.py:7: in <module>
    import pexpect
E   ModuleNotFoundError: No module named 'pexpect'

Unable to perform editable installation

pip install -e . from repository root fails, even with latest pip.

$ pip install -e .
Obtaining file:///Users/ssbarnea/c/os/pdbr
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: icecream<3.0.0,>=2.1.0 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from pdbr==0.7.2) (2.1.3)
Requirement already satisfied: rich<13.0.0,>=12.0.0 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from pdbr==0.7.2) (12.5.1)
Requirement already satisfied: sqlparse<0.5.0,>=0.4.2 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from pdbr==0.7.2) (0.4.2)
Requirement already satisfied: colorama>=0.3.9 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from icecream<3.0.0,>=2.1.0->pdbr==0.7.2) (0.4.5)
Requirement already satisfied: pygments>=2.2.0 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from icecream<3.0.0,>=2.1.0->pdbr==0.7.2) (2.13.0)
Requirement already satisfied: executing>=0.3.1 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from icecream<3.0.0,>=2.1.0->pdbr==0.7.2) (0.10.0)
Requirement already satisfied: asttokens>=2.0.1 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from icecream<3.0.0,>=2.1.0->pdbr==0.7.2) (2.0.8)
Requirement already satisfied: commonmark<0.10.0,>=0.9.0 in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from rich<13.0.0,>=12.0.0->pdbr==0.7.2) (0.9.1)
Requirement already satisfied: six in /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages (from asttokens>=2.0.1->icecream<3.0.0,>=2.1.0->pdbr==0.7.2) (1.16.0)
Installing collected packages: pdbr
  Attempting uninstall: pdbr
    Found existing installation: pdbr 0.7.2
    Uninstalling pdbr-0.7.2:
      Successfully uninstalled pdbr-0.7.2
  Running setup.py develop for pdbr
    error: subprocess-exited-with-error

    × python setup.py develop did not run successfully.
    │ exit code: 1
    ╰─> [1 lines of output]
        ERROR: Can not execute `setup.py` since setuptools is not available in the build environment.
        [end of output]

    note: This error originates from a subprocess, and is likely not a problem with pip.
  Rolling back uninstall of pdbr
  Moving to /Users/ssbarnea/.cache/cpython/Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages/pdbr/
   from /Users/ssbarnea/.cache/cpython/Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages/~dbr
  Moving to /Users/ssbarnea/.pyenv/versions/3.11-dev/bin/pdbr
   from /private/var/folders/32/1xrphgzd4xv777syxjtkpdw80000gn/T/pip-uninstall-65cx047u/pdbr
  Moving to /Users/ssbarnea/.pyenv/versions/3.11-dev/bin/pdbr_telnet
   from /private/var/folders/32/1xrphgzd4xv777syxjtkpdw80000gn/T/pip-uninstall-65cx047u/pdbr_telnet
  Moving to /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages/pdbr-0.7.2.dist-info/
   from /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages/~dbr-0.7.2.dist-info
  Moving to /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages/pdbr/
   from /Users/ssbarnea/.pyenv/versions/3.11-dev/lib/python3.11/site-packages/~dbr
error: subprocess-exited-with-error

× python setup.py develop did not run successfully.
│ exit code: 1
╰─> [1 lines of output]
    ERROR: Can not execute `setup.py` since setuptools is not available in the build environment.
    [end of output]

This is likely a side-effect of using poetry and I am afraid I cannot help with that, me being stubborn to keep using the setuptools and setuptools-scm packaging. No need to explain why ;)

Ipython 8.0

Hi,

Do you plan on supporting Ipython 8.0? I tried it with pdbr and the only issue (as I'm aware of) was a

Traceback (most recent call last):
  File "....py", line 234, in <module>
    f(0)
  File "....py", line 126, in ...
    breakpoint()
  File ".../pdbr/__main__.py", line 13, in set_trace
    pdb_cls = _pdbr_cls(context=context, show_layouts=show_layouts)
  File ".../pdbr/utils.py", line 92, in _pdbr_cls
    return klass()
  File ".../pdbr/_pdbr.py", line 72, in __init__
    super().__init__(**init_kwargs)
  File ".../IPython/terminal/debugger.py", line 29, in __init__
    self.pt_init(pt_session_options)
  File ".../pdbr/_pdbr.py", line 84, in pt_init
    func(pt_session_options)
  File ".../IPython/terminal/debugger.py", line 78, in pt_init
    history=self.debugger_history,
AttributeError: 'RichPdb' object has no attribute 'debugger_history'

I fixed it by simply adding

                self.debugger_history = FileHistory(self._ipython_history_file)

before or after self.debugger_history = FileHistory(self._ipython_history_file) in pdbr/_pdbr.py::pt_init.

In Ipython, the code that uses those attributes is awkward and there seems not to be a workaround; If we only put one of the 2 lines, we cannot get the right file.

But maybe there is a reason why you want to stick with 7.X?

Thanks!

Support for ANSI color codes

Since pdbr uses rich under the hood, it would be nice to support ANSI color codes.

A minimal example:

import pdbr
from rich.console import Console


class Dummy:
    def __repr__(self):
        console = Console()
        with console.capture() as capture:
            console.print("[red]hello[/red]")
        return capture.get()


if __name__ == "__main__":
    dummy = Dummy()
    breakpoint()

which prints

[1m[31mhello[1m[0m

ipdb seems to support this.

pdbr version 0.7.6
rich version: 13.1.0

Vars doesn't provide vars of the class instance

Vars of the object doesn't return actual vars of the instance of the class. What I'm doing wrong?
How to check vars of the object?

Without pdbr:

With pdbr:

Request: be able to search the source code

One of the limitations of pdb (vs the Perl debugger for example) is to be able to search the source code/text of the file being debugged. For example, if I want to set a breakpoint at a specific line that has the variable say my_var, I would be able to do so by just typing something like:
/my_var
and pdbr can jump to the first instance of my_var in the code.
Repeating the action with either /my_var or a simple /, would jump to the next occurrence of my_var, and loop back to the beginning of the file if needed.

What do you think?

(V)ars get distorted view

First of all, thanks for pdbr. It's amazing and I use it every day now! Everyting works great, except I have a bug in table view.
For instance, I have three args, but it partially shows only one and the view is distorted (pdbr prompt is horizontally offset).
UPD: Similar issue with vt command now.
UPD 2: Before it was great, now it happens from time to time. Not sure what cause it, I don't change anything in related code.

I'm using v0.8.2

print as default action when DataFrame variable entered

In ipdb you can type df (for example) in terminal to view a summary of a dataframe object, however in pdbr it it tries to assert the truth value which is less useful:

(Pdbr) df
*** ValueError: The truth value of a DataFrame is ambiguous. Use a.empty, a.bool(), a.item(), a.any() or a.all().

pyreadline3

Hi, I was testing out this package and noticed that for Windows you may want to update to pyreadline3, which is an actively maintained fork of pyreadline. See: https://github.com/pyreadline3/pyreadline3#pyreadline3

pdbr/pyproject.toml

Line 31 in d8d589e

pyreadline = {version="^2.1", markers="sys_platform == 'win32'"}

Could be:

pyreadline3 = {version = "^3.4.1", markers = "sys_platform == \"win32\""}

print less for `ll` (`longlist`)

Hi! It's me again.

I notice that the ll in pdbr prints the whole source file for the current frame instead of only printing the current function (as in ipdb). This can sometimes make debugging a little bit clumsy since we might need to scroll up through a lot of unrelated code to locate the actual frame. Although l gives a more compact output, it's often not enough to see just the 10 lines around the cursor.

In ipdb (actually in IPython), they use inspect to locate the actual line range of the current frame. I suppose we could take a similar approach and pass the line_range to _get_syntax_for_list?

    def getsourcelines(self, obj):
        lines, lineno = inspect.findsource(obj)
        if inspect.isframe(obj) and obj.f_globals is self._get_frame_locals(obj):
            # must be a module frame: do not try to cut a block out of it
            return lines, 1
        elif inspect.ismodule(obj):
            return lines, 1
        return inspect.getblock(lines[lineno:]), lineno+1

    def do_longlist(self, arg):
        """Print lines of code from the current stack frame.

        Shows more lines than 'list' does.
        """
        self.lastcmd = 'longlist'
        try:
            lines, lineno = self.getsourcelines(self.curframe)
        except OSError as err:
            self.error(err)
            return
        last = lineno + len(lines)
        self.print_list_lines(self.curframe.f_code.co_filename, lineno, last)
    do_ll = do_longlist

i.e. replace the with_line_range argument here with line_range and set the default to None.

pdbr/pdbr/_pdbr.py

Lines 128 to 142 in 234106e

	def _get_syntax_for_list(self, with_line_range=False):
	line_range = None
	if with_line_range:
	first = max(1, self.curframe.f_lineno - 5)
	line_range = first, first + 10
	filename = self.curframe.f_code.co_filename
	highlight_lines = {self.curframe.f_lineno}
	return Syntax.from_path(
	filename,
	line_numbers=True,
	theme=self._theme or DEFAULT_THEME,
	line_range=line_range,
	highlight_lines=highlight_lines,
	)

And do_list could invoke _get_syntax_for_list with no arguments and do_longlist with the line_range obtained from inspect?

What do you think?