Hacker News Reader

Comment by yason | Hacker News Reader

Happy to see new tools for debugging. Yet it's the good old print that I most often end up using. Debugging is very context-sensitive: adding prints makes sense because I know exactly what I'm interested in, and I can drill down on that without being disturbed by anything else. I can print low-level stuff or high-level indicators, depending where my debugging takes me. There's no ready-made recipe for that.

Some codebases have built-in logging or tracing functionality: you just flick a switch in a module and begin to get ready-made prints from all the interesting parts. But I've found myself never using those: they are not my prints, they do not come from the context I'm in and they don't have a meaning.

Use what you want but please don't underestimate prints.

View on HN

I've definitely had the experience of using custom_logger.log("something"), then checking the system log. Nope, no there, must be in /var/log/app ... nope. Hmm oh I know! I'll turn up the logging in the config file, wherever that is. Still nothing. Did I need to compile in some flag?

Screw it. print, run directly from shell, done.

Fuck var/log/app.

honestly, fuck the whole standard logging library in Python. It is the most infuriating thing to use. log4j has a lot to answer for

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 (for instance if you, God forbid, made the mistake of adhering to PEP-8 and sticking your import statements at the top) won't use your configuration - and thus send their log messages, again, nowhere.

Also, it's slow as hell.

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?)

Or you know you could just type "print".

Assuming you use Python, you might like this library - https://github.com/robdmc/behold

It gives you contextual debugging - so you can put fancy prints throughout a function but they are silent unless some context is true. It's useful for when you have a hot path that is executed a lot but you only want debug prints for one of those invocations.

I pretty exclusively rely on prints and intuition. Honestly I've implemented logging frameworks in different production situations and never gotten use out of them. Like you say - they don't answer the questions you need answered.

If you're going to use print debugging I highly recommend the package "q". It's print debugging on steroids.

Always logs to /tmp/q no matter what stdout redirects the app has set up. Syntax highlighting. Context dumping. Dumps large values to separate files. Etc.

Log points are awesome. Like break points but they add print/log. First seen in nodejs via vscode; not sure if python has anything like it. Can even attach to remote running process and add them.

Python extension for VSCode supports logpoints.

In general, something like this has been around in IDEs for a very long time - e.g. Visual Studio proper added them back in 2005, except it calls them "tracepoints".

Reply on news.ycombinator.com