andy-landy/traceback_with_variables

Adds variables to python traceback. Simple, lightweight, controllable. Debug reasons of exceptions by logging or pretty printing colorful variable contexts for each frame in a stacktrace, showing every value. Dump locals environments after errors to console, files, and loggers. Works in Jupyter and IPython. Install with pip or conda.

traceback_with_variables's Issues

How to reduce the output to a minimum?

Hi,

my use case for traceback_with_variables is mainly during development time. Therefore I just need a small overview what was wrong with the variables that actually caused the exception.

My question is: how can I customize it that the extra output that traceback_with_variables generates only comprises the very variables that lead to the exception?

Example:

Without using it, for this:

# from traceback_with_variables import activate_by_import
def main():
    n = 0
    x = 15
    print(1 / n)

main()

I get:

/home/usesr/venv/numba/bin/python3.6 /home/usesr/PycharmProjects/myProject/attic04.py
Traceback (most recent call last):
  File "/home/usesr/PycharmProjects/myProject/attic04.py", line 7, in <module>
    main()
  File "/home/usesr/PycharmProjects/myProject/attic04.py", line 5, in main
    print(1 / n)
ZeroDivisionError: division by zero

Process finished with exit code 1

With using it, I get:

/home/usesr/venv/numba/bin/python3.6 /home/usesr/PycharmProjects/myProject/attic04.py
Traceback with variables (most recent call last):
  File "/home/usesr/PycharmProjects/myProject/attic04.py", line 7, in <module>
    main()
      __name__ = '__main__'
      __doc__ = None
      __package__ = None
      __loader__ = <_frozen_importlib_external.SourceFileLoader object at 0x7f78c2d32f28>
      __spec__ = None
      __annotations__ = {}
      __builtins__ = <module 'builtins' (built-in)>
      __file__ = '/home/usesr/PycharmProjects/myProject/attic04.py'
      __cached__ = None
      activate_by_import = <module 'traceback_with_variables.activate_by_import' from '/home/usesr/venv/numba/lib/python3.6/site-packages/traceback_with_variables/activate_by_import.py'>
      main = <function main at 0x7f78c2d58e18>
  File "/home/usesr/PycharmProjects/myProject/attic04.py", line 5, in main
    print(1 / n)
      x = 15
      n = 0
builtins.ZeroDivisionError: division by zero

Process finished with exit code 1

Would it be possible to configure it (at one place in my code) that I only get this output:

/home/usesr/venv/numba/bin/python3.6 /home/usesr/PycharmProjects/myProject/attic04.py
Traceback (most recent call last):
  File "/home/usesr/PycharmProjects/myProject/attic04.py", line 7, in <module>
    main()
  File "/home/usesr/PycharmProjects/myProject/attic04.py", line 5, in main
    print(1 / n)
    n = 0
ZeroDivisionError: division by zero

Process finished with exit code 1

(so:
n = 0
lead to the exception, but
x = 15
was not part of the game.

As I have a lot of variables in my code, I get overwhelmed by the output and it takes me also time to find the value of the variable in the output that was causing the exception.

If I just could use a different import, that would be perfect for me :-) )

Add optional colorama support for windows old-schoolers

Add permanent python patching

Add colors to printed message

Publish wheel on pypi

For speedup installation, it will be nice if the wheel will be published on PyPI. It is nice because there is no need to execute any code during installation,

Add deny/allow lists for variables to print, add custom pretty printers

Recommendation to use in prod might have negative privacy implications

In the current README for this project, I've noticed the following part:

Should I use it after debugging is over, i.e. in production?
Yes, of course! That way it might save you even more time.

I think that this is a dangerous advice to provide when you consider software that might be dealing with user data (e.g. serving user queries over the network, processing database entries, etc.). You could easily end up with user data or secrets being accidentally stored in the app's debug logs, and:

• Debug logs might have a different retention policy than the data would normally have (e.g. data only stored in RAM normally might end up being persisted to disk for an undefined amount of time)
• Access control policy might be more relaxed for the debug logs than for raw access to the data itself. For example, this might end up leaking a secret to a developer that might not have direct access to that secret normally (e.g. it's passed through the environment or something like that).

See https://techcrunch.com/2019/03/21/facebook-plaintext-passwords/ for a precedent which this advice could accidentally end up reproducing.

I don't have a suggested rewording, but I think the caveats should probably be made clearer to potential users of the library.

For a special use case of uncontrolled exception printing (some web-frameworks with multiple processes and own handlers), override standard formatters

Rogue! To use with caution indeed.

Add globals

For multiline return statements show more than the first line

Now only the first line in showed.

add detailed docs and recipies

Add package to conda

traceback_with_variables is not safe for production use due to password leaking, yet the documentation states "keep for production use"

Hi -

I am receiving CVE reports that my library (SQLAlchemy) is dumping passwords into log files. it of course is not, they are using this package in production to dump all private variables into their logs. I don't see any mechanism by which traceback_with_variables could recognize password strings that are necessarily present as cleartext within third party libraries.

I would propose that traceback_with_variables' documentation be amended to note that this tool is not safe for production use in any scenario where there are passwords or other secrets present at runtime. That way I can point people to this documentation when my package (or any of thousands of other packages that receive a password and/or secret within a private variable) is claimed to have CVEs in it.

Demo:

from traceback_with_variables import activate_by_import

def connect_to_something_witha_secret(host, username, password):
    raise Exception(f"could not connect to host: {host}")


def go():
    connect_to_something_witha_secret(
        "fakehost", "scott", "super_secret_password"
    )


go()

output:

Traceback with variables (most recent call last):
  File "/mnt/photon_home/classic/dev/sqlalchemy/test4.py", line 13, in <module>
    go()
      ...skipped... 12 vars
  File "/mnt/photon_home/classic/dev/sqlalchemy/test4.py", line 8, in go
    connect_to_something_witha_secret(
  File "/mnt/photon_home/classic/dev/sqlalchemy/test4.py", line 4, in connect_to_something_witha_secret
    raise Exception(f"could not connect to host: {host}")
      host = 'fakehost'
      username = 'scott'
      password = 'super_secret_password'
builtins.Exception: could not connect to host: fakehost

Support flask, streamlit etc. in even more convenient way, so no extra code is needed at all

Add comparison to other similar modules, List features and use-cases and all

Add monkey patching

Add function to get traceback lines

Add external mode like `python -m tool myscript.py ...` to debug external readonly code

Is "NoReturn" the proper annotation for global_print_exc()?

The NoReturn type indicates the function either never terminates or always throws an exception:

From PEP-484:

The typing module provides a special type NoReturn to annotate functions that never return normally. For example, a function that unconditionally raises an exception..

By having it set to NoReturn, all the code after the call to global_print_exc() is "dimmed" in type-aware IDEs like VS Code. (For example, NoReturn makes sense for annotating sys.exit() with the visual indication that none of the code after it will ever execute.)

Since the function is simply setting sys.excepthook, shouldn't the return type simply be None, or am I missing something?