Python's missing debug print command and other development tools.

Overview

python devtools

CI Coverage pypi versions license

Python's missing debug print command and other development tools.

For more information, see documentation.

Install

Just

pip install devtools[pygments]

pygments is not required but if it's installed, output will be highlighted and easier to read.

devtools has no other required dependencies except python 3.6, 3.7, 3.8 or 3.9. If you've got python 3.6+ and pip installed, you're good to go.

Usage

from devtools import debug

whatever = [1, 2, 3]
debug(whatever)

Outputs:

test.py:4 <module>:
    whatever: [1, 2, 3] (list)

That's only the tip of the iceberg, for example:

import numpy as np

data = {
    'foo': np.array(range(20)),
    'bar': {'apple', 'banana', 'carrot', 'grapefruit'},
    'spam': [{'a': i, 'b': (i for i in range(3))} for i in range(3)],
    'sentence': 'this is just a boring sentence.\n' * 4
}

debug(data)

outputs:

python-devtools demo

Usage without Import

modify /usr/lib/python3.8/sitecustomize.py making debug available in any python 3.8 code

# add devtools debug to builtins
try:
    from devtools import debug
except ImportError:
    pass
else:
    __builtins__['debug'] = debug
Comments
  • Feature/color on win

    Feature/color on win

    Problem:

    The problem is the missing support for colors on windows machines and is described in #55.

    Changes:

    • I refactored the devtools.debug.Debug._env_bool classmethod as a function env_bool in devtools.prettier Reason: The method was not necessary to be a classmethod so I refactored it near env_true function which is used by the method.
    • I added tests for new function env_bool.
    • I introduced the highlight module which takes the roll to distinguish if highlighting is used. More info below
    • I added tests for the new highlight`module.
    • I changed Debug.__init__ and Debug.__call__ for the use of the new highlight.use_highlight function.

    highlight module

    On import the module will, when on a windows machine, try to activate windows ANSI support by setting the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag via SetConsoleMode. See here for more info: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences. Depending on the outcome the color_active variable will be set.

    The code which does the work was posted here: https://bugs.python.org/msg291732. Truth be told I only kinda get what the code does but I think the author knows what he does. I tested it on two Win10 machines and it works.

    Next there is the use_highlight function. It took over the work to distinguish if DebugOutput.str function called by Debug.__call__ should use highlighting. The function will first check if the Debug class instance got created with highlight=True. If not set it will check the PY_DEVTOOLS_HIGHLIGHT environment variable. If also not set it decides by checking if isatty(file_) and color_active variable are True. The latter part is new and the variable gets set on import (see above). The part before is just the old behavior.

    fixes #55

    EDIT: Info: My added tests succeed on windows but 21 others do not.

    opened by Cielquan 19
  • Allow executing dependency to be >1.0.0

    Allow executing dependency to be >1.0.0

    Closes #114

    I just tested it with executing==1.2.0 and asttokens==2.1.0 and everything seems to work, the tests pass.

    This will allow users to update executing to a version greater than 1.0.0, for example in the case of global installation.

    Please let me know if there is anything that would prevent this change from being possible. I checked the executing's API and there wasn't any breaking change.

    opened by staticf0x 10
  • Use executing and asttokens

    Use executing and asttokens

    This brings in two dependencies to do the heavy lifting for debug:

    • https://github.com/alexmojaki/executing finds the AST node
    • https://github.com/gristlabs/asttokens converts AST nodes to source code

    Both are very well tested and reliable and are used in several other libraries with no issues, including https://github.com/gruns/icecream. You'll note that several test cases no longer give warnings. In particular this fixes #47 and #71.

    executing can identify the AST node in almost all situations, which means:

    • #69 will be easy to implement, not just in variable assignments but also in things like list comprehensions as a commenter mentions.
    • Any function name is allowed, e.g. from devtools import debug as dbg will work. In fact the function can be any expression.
    opened by alexmojaki 10
  • debug() output suddenly styled weirdly

    debug() output suddenly styled weirdly

    Hi,

    I've been using the debug() function of devtools to print out some data structures for about 1-2 months now and I've been loving it!

    After taking a break from a Python program for about 2 weeks I've gone back to start improving it again and I've noticed that now, when I use debug(), the colorized output looks very weird. Since I haven't seen any other GitHub issues on the subject I'm sure the problem is on my end, but I can't figure out what it is.

    To simplify things, I've created a new venv, installed devtools and Pygments using the suggested pip install devtools[pygments]:

    ❯ pip list
    Package    Version
    ---------- -------
    devtools   0.6
    pip        20.2.4
    Pygments   2.7.1
    setuptools 49.2.1
    
    ❯ python -V
    Python 3.8.6
    

    and created the simplest program I could think of:

    #!/usr/bin/env python
    
    from devtools import debug
    
    a = 5
    
    debug(a)
    

    Still, the output is like this:

    image

    I normally use Bash on ArchLinux, but I've tried running this in Fish with the same result. I have installed a fresh Fedora 32 Workstation in a VM, created a new venv, and tried the same program, and get the same result.

    I really don't understand why I am suddenly getting this results and what I am doing wrong.

    Any tips/hints on where I should look to troubleshoot further? Thanks.

    opened by radcool 9
  • Defer importing `devtools` in `sitecustomize.py`.

    Defer importing `devtools` in `sitecustomize.py`.

    It's convenient to be able to use debug() as if it were a builtin function, but importing devtools directly in sitecustomize.py is a pretty significant performance hit for every invocation of python that doesn't use debug(). Specifically, this import takes 100-200 ms, which is a noticeable delay for interactive sessions and short-running scripts:

    $ python -X importtime -c 'import devtools'
    

    While it would probably be possible to make devtools faster to import, the best solution is simply to avoid importing devtools unless it will be used. It took me a while to figure out how to do this, but in the end the code is pretty clear and succinct, and I think it will be useful to others:

    # sitecustomize.py
    class lazy_debug:
        @property
        def __call__(self):
            from devtools import debug
            return debug
    
    __builtins__['debug'] = lazy_debug()
    

    This PR updates the README file to include the above snippet.

    opened by kalekundert 8
  • how __pretty__ works

    how __pretty__ works

    I'll describe fully how the __pretty__ unofficial dunder method is used by devtools on the remote off chance that @willmcgugan might adopt a similar thing in rich.

    This approach seems to work but is completely unofficial and wasn't developed in collaboration with others, so might require changes. I'd be very happy to support a changes to this, particularly if it can be somewhat backwards compatible.

    The Idea

    Provide a way for objects to describe how they should be displayed in "rich" (no pun intended) contexts, without moving all the logic of pretty printing into the object.

    The implementation

    objects which want to be pretty printed include a __pretty__ method with takes as arguments:

    • fmt a callable which takes one argument (usage described below)
    • extra **kwargs in case we want to pass more things to the method later

    It yields (or returns a list of) any of the following:

    • string, in which case that string is printed on the current line and the current indentation
    • int, in which case:
      • 1 means increase the indent by one level (4 spaces, 2 spaces, 1 tab, whatever you want it to mean)
      • -1 means decrease the indent by one level
      • 0 means new line, same indent
      • I think other numbers can be used to increase or decrease the indent more (e.g. 2 -> increase by two levels), but I can't remember if this is actually implemented, it's generally not needd
    • the result of fmt(<whatever>) in which case the application calling __pretty__ can decide how to render the argument to fmt(). This is useful for recursive pretty printing - e.g. a custom type of list doesn't need to know how to render all it's values.

    An example

    Here' is the __pretty__ method from the reusable Representation method in pydantic with more comments:

        def __pretty__(self, fmt: Callable[[Any], Any], **kwargs: Any) -> Generator[Any, None, None]:
            # show the name of the class together with an opening bracket so it looks a bit like a instance definition:
            yield self.__repr_name__() + '('
            # new line and increase the indent
            yield 1
            for name, value in self.__repr_args__():
                # if this class wants to show name value pairs, show '<name>=`
                if name is not None:
                    yield name + '='
                # render the value, devtools (or any tool calling this) can decide how to display the value
                yield fmt(value)
                # add a comma to the end of the line to keep it looking like an instance definition
                yield ','
                # new line without a change of indent
                yield 0
            # decrease indent, no extra new line
            yield -1
            # closing bracket to keep it looking a bit like python
            yield ')'
    

    with self.__repr_name__() --> 'TheName' and self.__repr_args__() --> [('x', 1), ('y', 2), (None, 3)], it might display

    TheName(
        x=1,
        y=2
        3,
    )
    
    opened by samuelcolvin 6
  • debug and pprint not working with pydantic classes

    debug and pprint not working with pydantic classes

    Hi,

    thanks for devtools I use it quite a lot. Now I stumbled over the following:

    >>> from devtools import debug
    
    >>> class W:
    ...     pass
    
    >>> debug(W)
    <stdin>:1 <module> (no code context for debug call, code inspection impossible)
        <class '__main__.W'> (type)
    
    >>> class W(:
    ...     pass
    >>> from pydantic import BaseModel
    
    >>> debug(BaseModel)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 122, in __call__
        s = d_out.str(highlight)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 85, in str
        return prefix + '\n    ' + '\n    '.join(a.str(highlight) for a in self.arguments)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 85, in <genexpr>
        return prefix + '\n    ' + '\n    '.join(a.str(highlight) for a in self.arguments)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 45, in str
        s += pformat(self.value, indent=4, highlight=highlight)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/prettier.py", line 80, in __call__
        self._format(value, indent_current=indent, indent_first=indent_first)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/prettier.py", line 94, in _format
        gen = pretty_func(fmt=fmt, skip_exc=SkipPretty)
      File "pydantic/utils.py", line 263, in pydantic.utils.Representation.__pretty__
    TypeError: __pretty__() takes exactly 2 positional arguments (0 given)
    
    __pretty__() takes exactly 2 positional arguments (0 given)
    
    >>> class W(BaseModel):
    ...     pass
    
    >>> debug(W)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 122, in __call__
        s = d_out.str(highlight)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 85, in str
        return prefix + '\n    ' + '\n    '.join(a.str(highlight) for a in self.arguments)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 85, in <genexpr>
        return prefix + '\n    ' + '\n    '.join(a.str(highlight) for a in self.arguments)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/debug.py", line 45, in str
        s += pformat(self.value, indent=4, highlight=highlight)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/prettier.py", line 80, in __call__
        self._format(value, indent_current=indent, indent_first=indent_first)
      File "/Users/weissl/.pyenv/versions/3.8.2/envs/cauldron/lib/python3.8/site-packages/devtools/prettier.py", line 94, in _format
        gen = pretty_func(fmt=fmt, skip_exc=SkipPretty)
      File "pydantic/utils.py", line 263, in pydantic.utils.Representation.__pretty__
    TypeError: __pretty__() takes exactly 2 positional arguments (0 given)
    
    __pretty__() takes exactly 2 positional arguments (0 given)
    
    >>>
    

    Could you please give me a hint what I am doing wrong here?

    opened by ludwig-weiss 6
  • Use secure builtins standard module, instead of the __builtins__

    Use secure builtins standard module, instead of the __builtins__

    Due to documentation, it seems that using __builtins__ directly is not reliable. Instead they were using the __builtin__ module which was renamed to builtins.

    Having __builtins__ and __builtin__ both is clearly a bad idea.

    [Python-Dev] __builtin__ vs __builtins__

    I hope this helps, as I am just starting with open source contributions.

    opened by 0xsirsaif 5
  • Type checking improvements

    Type checking improvements

    • Add a PEP 561 marker file (py.typed).
    • Run mypy during CI.
    • Update black to avoid https://github.com/pallets/click/issues/2225
    • Update mkdocs to avoid https://github.com/mkdocs/mkdocs/issues/2799
    • Disable mkdocs strict mode to avoid https://github.com/mkdocs/mkdocs/issues/2252
    opened by bringhurst 5
  • Instructions for using without import fail on Python 3.10

    Instructions for using without import fail on Python 3.10

    https://python-devtools.helpmanual.io/usage/#usage-without-import

    Suggests the following snippet:

        __builtins__['debug'] = debug
    

    In python 3.10 (at least, only version tried), referencing builtins directly gives "TypeError: 'module' object is not subscriptable"

    builtins.dict, however, is subscriptable.

    That figuring out where sitecustomize.py (or usercustomize.py) actually can be put so it gets properly executed on startup on a multi-python and/or brew (linuxbrew) system is an absolute nightmare is a different issue and not one I'd expect python-devtools to address particularly.

    opened by ssteinerx 5
  • [Bug] import statement in method: 'error parsing code, unable to find

    [Bug] import statement in method: 'error parsing code, unable to find "debug" function statement'

    Bug

    When the from devtools import debug statement occurs within a method (as opposed to at toplevel of the module), an "error parsing code" message is printed.

    Min repro:

    The following works as expected:

    # tmp.py
    from devtools import debug
    def foo():
        debug(123)
    foo()
    
    $ python tmp.py
    tmp.py:4 foo
        123 (int)
    

    But if you put the import statement inside the method, there is an error:

    # tmp2.py
    def foo():
        from devtools import debug
        debug(123)
    foo()
    
    $ python tmp2.py
    tmp2.py:4 foo (error parsing code, unable to find "debug" function statement)
        123 (int)
    
    opened by Jasha10 5
  • `insert_assert`

    `insert_assert`

    we should move https://github.com/samuelcolvin/dirty-equals/pull/51 to this package.

    Function should be debug.insert_assert, but we still need the library to become a pytest plugin so tests with insert_assert can fail.

    opened by samuelcolvin 0
  • `inspect` / `vars` function

    `inspect` / `vars` function

    (I thought this was already an issue, but I checked and it seems it only existed in my head)

    I want a way to pretty-print pertinent attributes of an object, like vars(...) but more intelligent - in particular it should try to inspect __slots__ if __dict__ is not available.

    This might be as simple as sugar around the following POC, but there are probably edge cases I haven't thought about.

    I guess we should expose this via debug.inspect().

    Rough demo code of what I mean
    from __future__ import annotations
    from devtools import debug
    
    ignored_attributes = {
        '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__',
        '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
        '__init__', '__init_subclass__', '__le__', '__lt__', '__module__',
        '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
        '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '__slots__',
    }
    
    
    class DebugInspect:
        __slots__ = ('obj',)
    
        def __init__(self, obj: Any):
            self.obj = obj
    
        def __pretty__(self, fmt: Callable[[Any], Any], **kwargs: Any) -> Generator[Any, None, None]:
            yield self.obj.__class__.__name__ + '('
            yield 1
            # use __dict__ if possible to maintain order, also should be slightly faster
            obj_dict = getattr(self.obj, '__dict__', None)
            if obj_dict is not None:
                for name, value in obj_dict.items():
                    yield name + '='
                    yield fmt(value)
                    yield ','
                    yield 0
            else:
                for name in dir(self.obj):
                    if name not in ignored_attributes:
                        yield name + '='
                        yield fmt(getattr(self.obj, name))
                        yield ','
                        yield 0
            yield -1
            # closing bracket to keep it looking a bit like python
            yield ')'
    
    
    class Foo:
        def __init__(self):
            self.x = 1
            self.y = 2
            self._private = 3
            self.__custom_dunder__ = 4
    
    
    class Bar:
        __slots__ = 'x', 'y', '_private', '__custom_dunder__'
    
        def __init__(self):
            self.x = 1
            self.y = 2
            self._private = 3
            self.__custom_dunder__ = 4
    
    
    f = Foo()
    debug(DebugInspect(f))
    
    b = Bar()
    debug(DebugInspect(b))
    

    prints:

    foobar.py:61 <module>
        DebugInspect(f): Foo(
            x=1,
            y=2,
            _private=3,
            __custom_dunder__=4,
        ) (DebugInspect)
    foobar.py:64 <module>
        DebugInspect(b): Bar(
            __custom_dunder__=4,
            _private=3,
            x=1,
            y=2,
        ) (DebugInspect)
    
    opened by samuelcolvin 0
  • Option to include stack trace in `debug()` output?

    Option to include stack trace in `debug()` output?

    Today I was trying to debug an issue where a function of mine was unexpectedly being called from two places. I was using debug() within the function, but it only reports the file/line number/function that it was directly invoked from, which in this case I knew. I wanted to know where this function was being called from, so I looked for a way to get a full stack trace by doing something like debug(trace=True). As far as I can tell, this option doesn't exist yet.

    Is there interest in adding such an option? If so, I could probably try to make a PR in the near-ish future.

    opened by kalekundert 2
  • Is it ok that input args are printed twice?

    Is it ok that input args are printed twice?

    I get my "debugged" vars printed both by debug utils and as a return val, so in case of dataclasses or big dicts (for which it fits the most) it eats all screen space.

    Am I missing something or it works as expected?

    Python 3.10.2 (main, Jan 29 2022, 02:55:36) [GCC 10.2.1 20210110] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from devtools import debug
    >>> debug({'a': 1, 'b': 2})
    <stdin>:1 <module> (no code context for debug call, code inspection impossible)
        {
            'a': 1,
            'b': 2,
        } (dict) len=2
    {'a': 1, 'b': 2}
    
    opened by a1tus 10
  • Suggestion: adding parameter to configure the frame depth

    Suggestion: adding parameter to configure the frame depth

    First of all: I just discover devtools and I think it is a fantastic tool. I definitely plan to use it instead of my simple minded debugging helper.

    Currently, debug() is assumed to be called explicitly in a given module, with a hard-coded value for the frame in which it looks for information:

        def _process(self, args, kwargs) -> DebugOutput:
            """
            BEWARE: this must be called from a function exactly 2 levels below the top of the stack.
            """
            # HELP: any errors other than ValueError from _getframe? If so please submit an issue
            try:
                call_frame: 'FrameType' = sys._getframe(2)
            except ValueError:
                ...
    

    I would find it useful if the constant 2 could be a configurable parameter. For example, I could then define custom functions like the following:

    def handle_problem(*args, **kwargs):
        if dev_version:
            debug = Debug(additional_frame_depth=1)
            debug(*args, **kwargs)
        else:
            print("Internal problem: please report this case.")
    

    Obviously, I could currently do this by subclassing Debug, but I think that this might be a useful feature to have. I understand that the idea is to use devtools.debug during development and one would normally remove all traces of it for releases. However, I find it useful in one of my projects (friendly-traceback) to leave in place such debugging functions such that end-users are never exposed to tracebacks generated by my own project while still being able to cope with the unexpected.

    opened by aroberge 1
Releases(v0.10.0)
  • v0.10.0(Nov 28, 2022)

    • Use secure builtins standard module, instead of the __builtins__ by @0xsirsaif in https://github.com/samuelcolvin/python-devtools/pull/109
    • upgrade executing to fix 3.10 by @samuelcolvin in https://github.com/samuelcolvin/python-devtools/pull/110
    • Fix windows build by @samuelcolvin in https://github.com/samuelcolvin/python-devtools/pull/111
    • Allow executing dependency to be >1.0.0 by @staticf0x in https://github.com/samuelcolvin/python-devtools/pull/115
    • more precise timer summary by @banteg in https://github.com/samuelcolvin/python-devtools/pull/113
    • Python 3.11 by @samuelcolvin in https://github.com/samuelcolvin/python-devtools/pull/118

    New Contributors

    • @0xsirsaif made their first contribution in https://github.com/samuelcolvin/python-devtools/pull/109
    • @staticf0x made their first contribution in https://github.com/samuelcolvin/python-devtools/pull/115
    • @banteg made their first contribution in https://github.com/samuelcolvin/python-devtools/pull/113

    Full Changelog: https://github.com/samuelcolvin/python-devtools/compare/v0.9.0...v0.10.0

    Source code(tar.gz)
    Source code(zip)
  • v0.9.0(Jul 26, 2022)

    • fix format of nested dataclasses, #99 thanks @aliereno
    • Moving to pyproject.toml, complete type hints and test with mypy, #107
    • add install command to add debug to __builtins__, #108

    Full Changelog: https://github.com/samuelcolvin/python-devtools/compare/v0.8.0...v0.9.0

    Source code(tar.gz)
    Source code(zip)
  • v0.8.0(Sep 29, 2021)

    • test with python 3.10 #91
    • display SQLAlchemy objects nicely #94
    • fix tests on windows #93
    • show function qualname #95
    • cache pygments loading (significant speedup) #96
    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Sep 3, 2021)

    • switch to executing and asttokens for finding and printing debug arguments, #82, thanks @alexmojaki
    • correct changelog links, #76, thanks @Cielquan
    • return debug() arguments, #87
    • display more generators like map and filter, #88
    • display Counter and similar dict-like objects properly, #88
    • display dataclasses properly, #88
    • uprev test dependencies, #81, #83, #90
    Source code(tar.gz)
    Source code(zip)
  • v0.6.1(Oct 22, 2020)

  • v0.6(Jul 29, 2020)

    v0.6.0 (2020-07-29)

    • improve __pretty__ to work better with pydantic classes, #52
    • improve the way statement ranges are calculated, #58
    • drastically improve import time, #50
    • pretty printing for non-standard dicts, #60
    • better statement finding for multi-line statements, #61
    • colors in windows, #57
    • fix debug(type(dict(...))), #62
    Source code(tar.gz)
    Source code(zip)
  • v0.5.1(Oct 9, 2019)

  • v0.5(Jan 3, 2019)

  • v0.4(Dec 29, 2018)

    • remove use of warnings, include in output, #30
    • fix rendering errors #31
    • better str and bytes wrapping #32
    • add len everywhere possible, part of #16
    Source code(tar.gz)
    Source code(zip)
  • v0.3(Oct 11, 2017)

  • v0.2(Sep 14, 2017)

Owner
Samuel Colvin
Software developer and CTO @myhealthchecked. Python, TypeScript, rust.
Samuel Colvin
printstack is a Python package that adds stack trace links to the builtin print function, so that editors such as PyCharm can link you to the source of the print call.

printstack is a Python package that adds stack trace links to the builtin print function, so that editors such as PyCharm can link to the source of the print call.

null 101 Aug 26, 2022
Dahua Console, access internal debug console and/or other researched functions in Dahua devices.

Dahua Console, access internal debug console and/or other researched functions in Dahua devices.

bashis 156 Dec 28, 2022
A configurable set of panels that display various debug information about the current request/response.

Django Debug Toolbar The Django Debug Toolbar is a configurable set of panels that display various debug information about the current request/respons

Jazzband 7.3k Dec 31, 2022
A configurable set of panels that display various debug information about the current request/response.

Django Debug Toolbar The Django Debug Toolbar is a configurable set of panels that display various debug information about the current request/respons

Jazzband 7.3k Dec 29, 2022
An x86 old-debug-like program.

An x86 old-debug-like program.

Pablo Niklas 1 Jan 10, 2022
Django package to log request values such as device, IP address, user CPU time, system CPU time, No of queries, SQL time, no of cache calls, missing, setting data cache calls for a particular URL with a basic UI.

django-web-profiler's documentation: Introduction: django-web-profiler is a django profiling tool which logs, stores debug toolbar statistics and also

MicroPyramid 77 Oct 29, 2022
Never use print for debugging again

PySnooper - Never use print for debugging again PySnooper is a poor man's debugger. If you've used Bash, it's like set -x for Python, except it's fanc

Ram Rachum 15.5k Jan 1, 2023
A powerful set of Python debugging tools, based on PySnooper

snoop snoop is a powerful set of Python debugging tools. It's primarily meant to be a more featureful and refined version of PySnooper. It also includ

Alex Hall 874 Jan 8, 2023
Arghonaut is an interactive interpreter, visualizer, and debugger for Argh! and Aargh!

Arghonaut Arghonaut is an interactive interpreter, visualizer, and debugger for Argh! and Aargh!, which are Befunge-like esoteric programming language

Aaron Friesen 2 Dec 10, 2021
Debugger capable of attaching to and injecting code into python processes.

DISCLAIMER: This is not an official google project, this is just something I wrote while at Google. Pyringe What this is Pyringe is a python debugger

Google 1.6k Dec 15, 2022
🔥 Pyflame: A Ptracing Profiler For Python. This project is deprecated and not maintained.

Pyflame: A Ptracing Profiler For Python (This project is deprecated and not maintained.) Pyflame is a high performance profiling tool that generates f

Uber Archive 3k Jan 7, 2023
Parsing ELF and DWARF in Python

pyelftools pyelftools is a pure-Python library for parsing and analyzing ELF files and DWARF debugging information. See the User's guide for more deta

Eli Bendersky 1.6k Jan 4, 2023
Code2flow generates call graphs for dynamic programming language. Code2flow supports Python, Javascript, Ruby, and PHP.

Code2flow generates call graphs for dynamic programming language. Code2flow supports Python, Javascript, Ruby, and PHP.

Scott Rogowski 3k Jan 1, 2023
AryaBota: An app to teach Python coding via gradual programming and visual output

AryaBota An app to teach Python coding, that gradually allows students to transition from using commands similar to natural language, to more Pythonic

null 5 Feb 8, 2022
Full featured multi arch/os debugger built on top of PyQt5 and frida

Full featured multi arch/os debugger built on top of PyQt5 and frida

iGio90 1.1k Dec 26, 2022
VizTracer is a low-overhead logging/debugging/profiling tool that can trace and visualize your python code execution.

VizTracer is a low-overhead logging/debugging/profiling tool that can trace and visualize your python code execution.

null 2.8k Jan 8, 2023
A package containing a lot of useful utilities for Python developing and debugging.

Vpack A package containing a lot of useful utilities for Python developing and debugging. Features Sigview: press Ctrl+C to print the current stack in

volltin 16 Aug 18, 2022
A web-based visualization and debugging platform for NuPIC

Cerebro 2 A web-based visualization and debugging platform for NuPIC. Usage Set up cerebro2.server to export your model state. Then, run: cd static py

Numenta 24 Oct 13, 2021
Trace all method entries and exits, the exit also prints the return value, if it is of basic type

Trace all method entries and exits, the exit also prints the return value, if it is of basic type. The apk must have set the android:debuggable="true" flag.

Kurt Nistelberger 7 Aug 10, 2022