It should take a competent programmer about 30 minutes to create a nice log class with more flexibility for their particular application. On one hand thank you for sharing, on the other hand if I add this to my project at work my boss is going to scold me
Icecream: Never use print() to debug again in Python
161–170 of 271 posts
Re: Icecream: Never use print() to debug again in Python
#162Re: Icecream: Never use print() to debug again in Python
#163Earlier 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.
Because you shouldn’t have to change code, just to debug it. It’s okay though to add verbose logging as a feature. But just adding some print statements to debug code and remove them afterwards, is dangerous (you release sth different than you debugged).
I do it in a different branch & discard it afterwards. Having said that, I never meant print() should be used in place of a proper debugger. All I am saying is they both can complement each other and each one has its place & value. As for me, I find it quicker to add a few print statements and get a rough idea before firing up a debugger(if required). May be others are more proficient in using debuggers. But print() works for me.
Re: Icecream: Never use print() to debug again in Python
#164This library's 'ad copy' focuses on its ability to print the expression passed to the `log` function verbatim, but for those thinking about importing this library or something like it, I find that the most useful long-term benefit of a construction like this is this:
All short-term logging / debugging calls are now properly isolated.
Ordinarily, if you spot a `print` statement in code it's usually a left-over relic of some previous debug session. Or it's the command line printer, who knows?
With a call to ic, you know it's short-term logging and nothing else. You can search for them, you can spot them immediately in commit changelogs, you can write hooks if you want to ban them from ever appearing in certain branches, you can breakpoint them in your IDE, etcetera.
For many apps, _all_ print statements work like that, but I've worked on more than a few that have a 'print to standard out' component to them.
Re: Icecream: Never use print() to debug again in Python
#165LOL, first time I write a slogan catchy enough that other people copy it :) https://news.ycombinator.com/item?id=19717786 PySnooper: Never use print for debugging again
It seems like it was a coincidence. See comment thread:
https://github.com/gruns/icecream/commit/ee849b840eb34242aa2...
Re: Icecream: Never use print() to debug again in Python
#166Earlier 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.
The same thing happens all over Software really. Just because a tool is powerful is looked up as superior, or better. The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion. I legitimately believe print debugging is incredibly powerful (With a simple print I can check if a function is being called, how many times, if the…
> The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion.
Breakpoints are way worse on this dimension.
Re: Icecream: Never use print() to debug again in Python
#167Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster and just plainly worse in all aspects. Especially in Pycharm for me, it is incredibly easy. Even when running over ssh in remote computers I can use my debugger.
> Why don't people just use a debugger? I only speak for myself, but I find that time spent inside a debugger is "lost", and bound to be re-spent again and again if you ever find new problems with the same code. I pretty much prefer to add assertions, logging and comments to my program, that will stay there and make further re-reads easier and more useful. As a matter of principle, I never use a debugger (except for…
Then you are either using a bad debugger, or you're not using one properly. A good, fully-featured debugger allows you to store sessions and configurations for various efforts and problems you're trying to diagnose, along with your notes and links to relevant issues.
Re: Icecream: Never use print() to debug again in Python
#168Earlier quoted context omitted.
It depends on the situation. In general, debuggers give you much more contextual information, but using a debugger is extremely slow. To see what's going on, you have to step through your program, one line at a time, until the interesting thing happens. That can take ages. If you want to see how a specific function is behaving and it's called 100 times, it's a lot easier to look at a printed log of the 100 calls and…
> you have to step through your program, one line at a time You can set more than one breakpoint at a time. Hitting 'c' will get you to the next breakpoint, no matter where it is. > and step through it over and over No, you don't (shouldn't) do that. You write a conditional breakpoint which activates when something interesting happens.
OTOH if you're able to write `if bug_will_happen_on_next_line(): breakpoint()` you're pretty much done debugging.
Re: Icecream: Never use print() to debug again in Python
#169Earlier quoted context omitted.
I don't understand your wheel analogy, sorry. > You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. If you don't know where to put a breakpoint, how do you know where to put a print statement?
Imagine putting breakpoints in multiple tight loops in the stage of narrowing the search space. Imagine how many times you need to click next. A conditional breakpoint will only help if you know the condition you're looking for, but there's stage before that of "Well, what looks strange during execution". Also for multithreaded code, stopping one thread dead for long enough for a human to investigate it can inadverte…
What I imagine Macha is arguing for is that the cost of using print is extremely small, smaller at least than breakpoints.
No one is saying breakpoints are useless, sometimes printing is 'cheaper' in time and effort in order to locate the region code of code in which using breakpoints is cheaper.
Re: Icecream: Never use print() to debug again in Python
#170I use PySnooper[1] when code behavior deviates inscrutably from my mental model. Like Icecream, PySnooper exhorts, "Never use print for debugging again." A simple example:
import pysnooper
@pysnooper.snoop()
def add_up(numbers):
total = 0
for number in numbers:
total += number
return total
add_up([123, 456])
$ python example.py
Source path:... /home/joel/example.py
Starting var:.. numbers = [123, 456]
08:46:58.742543 call 4 def add_up(numbers):
08:46:58.742692 line 5 total = 0
New var:....... total = 0
08:46:58.742722 line 6 for number in numbers:
New var:....... number = 123
08:46:58.742755 line 7 total += number
Modified var:.. total = 123
08:46:58.742787 line 6 for number in numbers:
Modified var:.. number = 456
08:46:58.742818 line 7 total += number
Modified var:.. total = 579
08:46:58.742847 line 6 for number in numbers:
08:46:58.742876 line 8 return total
08:46:58.742898 return 8 return total
Return value:.. 579
Elapsed time: 00:00:00.000405