Live data from Hacker News

PySnooper: Never use print for debugging again

github.com

161–170 of 175 posts

Re: PySnooper: Never use print for debugging again

#161
post #160
post #158

Earlier quoted context omitted.

Why?

>>> import logging >>> logging.info('Hello, world!') >>> # right, my log message went nowhere Because by default, logging goes nowhere. And if you configure logging - using a most unintuitive config format (it's so weird that even the documentation about it can't be bothered to use it, but reverts to yaml to explain what it means!) - there's a good chance that loggers created before you got around to configure it (fo…

You know, you could start by reading the documentation and stick one logging.basicConfig() call in your entrypoint, instead of spreading that kind of misinformation.

Python's logging infrastructure is pretty bad but you fail to give any good, factual reason why it is. Instead you just vent your frustration on HN, making that platform all the more depressing to read.

Re: PySnooper: Never use print for debugging again

#163
post #160

Earlier quoted context omitted.

>>> import logging >>> logging.info('Hello, world!') >>> # right, my log message went nowhere Because by default, logging goes nowhere. And if you configure logging - using a most unintuitive config format (it's so weird that even the documentation about it can't be bothered to use it, but reverts to yaml to explain what it means!) - there's a good chance that loggers created before you got around to configure it (fo…

You know, you could start by reading the documentation and stick one logging.basicConfig() call in your entrypoint, instead of spreading that kind of misinformation. Python's logging infrastructure is pretty bad but you fail to give any good, factual reason why it is. Instead you just vent your frustration on HN, making that platform all the more depressing to read.

I for one am glad to hear this aired in a public forum, even though it took several pointless replies to get to the "hey, check out this bad default setting"... I'm learning Python as a distant third priority, I had only heard of pdb once, and I would have probably tripped over this logger that logs by default to nowhere at least once before I resorted to giving up and reading the documentation in anger.

Why is it this way, do you think? (Is it a reasoned stance? I would have expected the logger to send messages to stdout by default, so at the risk of getting a "Read the docs!" am I going to be equally surprised at the behavior of basicConfig?)

Re: PySnooper: Never use print for debugging again

#164
post #160

Earlier quoted context omitted.

>>> import logging >>> logging.info('Hello, world!') >>> # right, my log message went nowhere Because by default, logging goes nowhere. And if you configure logging - using a most unintuitive config format (it's so weird that even the documentation about it can't be bothered to use it, but reverts to yaml to explain what it means!) - there's a good chance that loggers created before you got around to configure it (fo…

You know, you could start by reading the documentation and stick one logging.basicConfig() call in your entrypoint, instead of spreading that kind of misinformation. Python's logging infrastructure is pretty bad but you fail to give any good, factual reason why it is. Instead you just vent your frustration on HN, making that platform all the more depressing to read.

Or you know you could just type "print".

Re: PySnooper: Never use print for debugging again

#166

While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a print statement is just fine, and anything else is overabstracting it. Not saying other options aren't nice to have available, just that there is nothing wrong with using a simple print statement in many situations.

I agree. Print is the most fundamental tool available to you: debuggers are kernel and hardware spanning monsters that introduce an external logic dependency. We don't advocate for more complexity than is necessary in other places.

"Simple is better than complex". The simplest tool that gets the job done, is the right one to choose for that situation.

Re: PySnooper: Never use print for debugging again

#167

As a very mediocre ruby programmer, is there an equivalent in ruby to this? If you have a little pattern that is more clever than 'puts' everywhere, please share, it would be well received by at least one person out there. Thanks!

Something that prints out the state after running each line of code? No, I don't think so, but I believe it wouldn't be too hard to rig up something similar with TracePoint - https://ruby-doc.org/core-2.2.0/TracePoint.html - which is a built in Ruby way to trace code execution.

For example, dump this into a file and run it:

    TracePoint.trace(:line) do |tp|
      STDERR.puts "Ran: #{File.readlines(tp.path)[tp.lineno - 1]}"
    end

    a = 10
    b = 5
    puts a
    a += b
    puts a
    puts b
It'll print out each line of code as it runs it. You could then parse each line for identifiers and print them out, etc. It'd be a project, but it's doable.

Re: PySnooper: Never use print for debugging again

#168

As a very mediocre ruby programmer, is there an equivalent in ruby to this? If you have a little pattern that is more clever than 'puts' everywhere, please share, it would be well received by at least one person out there. Thanks!

Check out byebug:

https://github.com/deivid-rodriguez/byebug

Re: PySnooper: Never use print for debugging again

#169
Really love this. Seems like it captures a whole bunch of interesting information when a function is invoked.

I love auto-loggers like this where you can selectively capture interesting bits.

This is the basis of reverse debugging I.e capturing chronological snapshots. Would love to see a Vscode extension that allows to step forward/backwards through time when an interesting thing happens.

Re: PySnooper: Never use print for debugging again

#170
post #148
post #142

Earlier quoted context omitted.

"Ram"? I went looking for a project called Ram but couldn't find one. Link?

It's the author of the package, the readme says: Copyright (c) 2019 Ram Rachum, released under the MIT license.

ah, thank you. I missed the forest for the trees.
Post reply on HN