python-devtools icon indicating copy to clipboard operation
python-devtools copied to clipboard

Is it ok that input args are printed twice?

Open a1tus opened this issue 3 years ago • 10 comments

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}

a1tus avatar Feb 27 '22 12:02 a1tus

This is normal, and is just what happens if you use debug by itself in the shell. There's not much reason to do that, but if you really want to, you can supress the extra printing from the shell by writing something like _=debug(...) instead so that it doesn't simply evaluate the expression.

alexmojaki avatar Feb 27 '22 12:02 alexmojaki

I was using it exactly like this :)

Thank you, so I'm closing it then.

a1tus avatar Feb 27 '22 22:02 a1tus

I think returning the arguments should be configurable via an env variable.

I don't use the return value much, and I can imagine it's annoying in ipython.

samuelcolvin avatar Feb 27 '22 22:02 samuelcolvin

Oh, that would be nice. In our case usage is primarily limited to python/ipython/django shell plus.

Writing _ = debug(x) of course wastes time.

I can also suggest to consider os.isatty but not sure if it will fit all cases.

a1tus avatar Feb 27 '22 22:02 a1tus

Ye I thought about os.isatty or similar, but I think it would be more confusing "black magic".

samuelcolvin avatar Feb 27 '22 22:02 samuelcolvin

os.isatty(sys.stdout.fileno()) gives the same thing in the shell and in regular scripts, I don't see how it would help.

Checking if the next bytecode instruction is a PRINT_EXPR might work.

alexmojaki avatar Feb 27 '22 22:02 alexmojaki

There is always an option to add separate func that just calls current debug with param to disable return like dbg, but again it depends whether you want to extend public contract.

a1tus avatar Feb 28 '22 09:02 a1tus

You can check if you're in ipython like https://github.com/samuelcolvin/pydantic/blob/9d631a3429a66f30742c1a52c94ac18ec6ba848d/pydantic/utils.py#L183

But overall I agree, I think a new method might be best.

samuelcolvin avatar Feb 28 '22 09:02 samuelcolvin

Sorry, I just start looking into this tool recently. But reading this issue I have a question... Why the debug should return the value? When you do print, it does not return anything, it just prints...

What is the root cause of the debug returning the value it is debugging? some chaining or what?

sshishov avatar Nov 24 '22 11:11 sshishov

So that if you have some code foo(bar()) you can change it to foo(debug(bar())) which is easier than b = bar(); debug(b); foo(b)

alexmojaki avatar Nov 25 '22 10:11 alexmojaki