Party on! I applaud this effort. As a UI/UX engineer I can say that there is no one debugging UI/UX experience to fit all. Of course there is the active/passive division between active debugging and logging. There are further usability divisions in both of those. As this is a passive/logging debugging scheme I'm sure there are those in the passive debugging community who will find this helpful, if not vocal.There is no one size fits all when it comes to usability although 99.9999% of software built only presents one usability experience and only begrudgingly provide the disabled community access as an after thought. A fairly significant percentage of the population is color blind and yet web sites still overly rely on red. Yby. You be you. The bane of all usability is one size fits all. Well met! We need more, not less, usability options.
Icecream: Never use print() to debug again in Python
121–130 of 271 posts
Re: Icecream: Never use print() to debug again in Python
#122Party on! I applaud this effort. As a UI/UX engineer I can say that there is no one debugging UI/UX experience to fit all. Of course there is the active/passive division between active debugging and logging. There are further usability divisions in both of those. As this is a passive/logging debugging scheme I'm sure there are those in the passive debugging community who will find this helpful, if not vocal.There is…
The split doesn't even run as deep as you describe it. Sometimes I use active debugging, sometimes I use passive debugging, depending on the situation. Sometimes I just want to see the output, so passive is fine, sometimes I want to control the flow and be able to inspect things more deeply. I don't think there are people who only use one or the other.
Re: Icecream: Never use print() to debug again in Python
#123You can do the same thing with Python 3.8+ by using f-strings and just appending "=" to the variable name: >>> print(f"{d['key'][1]=}") d['key'][1]='one'
Nice feature. Is there a way to globally enable/disable it? E.g.,
python3 myscript.py --enableFstringDebugging=true
if debug:
print (f"some useful debugging info")Re: Icecream: Never use print() to debug again in Python
#124Earlier quoted context omitted.
Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.
How is changing code simpler than literally clicking on the line number to set a breakpoint?
Depending on how complex your debugger is, it allows you to output values that might not be inspectable through the debugger. Especially computed values.
Debug printing also allows you to debug programs running in environments where you can't attach a debugger. For example, maybe halting the program causes the bug not to trigger. Or it's a remote system where you cannot attach a debugger for various reasons. Or the bug only happens in the optimized build, which in say C/C++ can make it quite tedious to walk through with a debugger.
Most of the time though I use print as "proactive debugging". Having detailed logs available is gold when customer calls with a blocking issue.
Re: Icecream: Never use print() to debug again in Python
#125> prints both its own arguments and the values of those arguments. That's not enough. Almost always I also want the argument type . Occasionally a unique (i.e. as precise as possible) sortable (i.e. with leading zeros) time stamp also comes useful.
> sortable (i.e. with leading zeros) time stamp
Not just with leading zeros but also written in the YYYY-MM-DD-HH-... format.
Re: Icecream: Never use print() to debug again in Python
#126I promise the 15 minutes it takes to learn to use the debugger will save years of your life
[deleted]
Re: Icecream: Never use print() to debug again in Python
#127The only thing I will say is that this would not meet my personal code review standards for logging. Rule number one is never put functional calls in a logging statement, only log static data. As optimistic as one might be that the 'ic' has no side effects, the most conservative approach is to never put anything that interacts with run-time behavior in a log statement. This is especially good practice when working in many code bases in many languages. If one gets comfortable with something like say 'ic' that has no side effects when wrapping function calls then one may assume this out of habit when interacting with other such utilities, other languages. The conservative approach is best in my experience and that is to never insert run-time code in log statements and only log static data.
Re: Icecream: Never use print() to debug again in Python
#128Earlier quoted context omitted.
TBF if you always run your programs in pycharm and use its debugger, you can trivially use non-suspending "evaluate and log" breakpoints instead of print.
But prints work equally well in any environment. I can remove prints by just checking out the latest version of the file.
> But prints work equally well in any environment.
GP say they "have debugger set in pycharm and use it all the time". So under the assumption (explicitly made in my comment) that they're always using PyCharm to run their program, that's not a concern.
> I can remove prints by just checking out the latest version of the file.
Thereby losing all the changes you've made while observing program behaviour, which may be less than desirable.
Meanwhile it's just as easy if not easier to disable or delete breakpoints from the View Breakpoints pane / window: https://i1.wp.com/cdn-images-1.medium.com/max/800/1*0wAP-w-a... you can just uncheck the "Python Line Breakpoints" box, or select all breakpoints and [Delete] them.
Re: Icecream: Never use print() to debug again in Python
#129Earlier quoted context omitted.
Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.
How is changing code simpler than literally clicking on the line number to set a breakpoint?
You said "click", I need to leave my keyboard.
Generally when I am coding I auto-run the tests on save. This means that to printf-debug I just add a message or two (and if I am coding I might already have a couple of useful ones lying around) and save. Then in less than a second I have a trace trough my program in the terminal. If I want to inspect a different variable I just add another print and run again.
With a debugger I need to kill my auto-run command, run the program, set breakpoints, type to see what variables I want to inspect, maybe switch stack frames, maybe step through a bit.
In my mind printf is like an automated debugger. I just put the info I want to see into the program and it does all of the printing for me. And when I find the problem I can just fix it and I am back to my edit-test cycle.
I'm not saying that there are no use cases for a debugger. For example I find variable-modification breakpoints very useful. As you mentioned if your edit-run cycle is slow then it may be faster to inspect a new variable in the debugger than adding another print statement. But when I just want to inspect values in my program I find printf sufficient and lower overhead. I'm sure part of my problem is that because I rarely use a debugger I am not as efficient, but I also think that printf-debugging is a very effective workflow for a wide variety of issues.
Re: Icecream: Never use print() to debug again in Python
#130Earlier quoted context omitted.
You can also use the breakpoint() introduced in py3.7 via PEP533 https://www.python.org/dev/peps/pep-0553/
Bump. This is the most correct way to debug python programs VS using print statement.
Debugging virtually anything real-time that interacts with other systems will require some kind of logging (of which printf() is the trivial case). Step-through debugging is great but far from universally applicable.