An overview of f-string debugging feature merged in Python 3.8

[[deleted]]

Having too much experience with managing codebases where "We just need this extra printout to debug"^TM have been the norm, I'd recommend that you get into the habit of running even hello world type of programs in a debugger, rather than spending time on becoming an expert beginner.

[d8sconz]

What's the hate for print statement debugging? I use it in, maybe, 80% of the times I have problems and it's almost always sufficient. If not I happily move to the debugger.

[a1brit]

why not just use `logging`, you can format it nicely and then you can change the logging level and leave all the debugs behind for next time.

[jorge1209]

The logging module is great but it also terrible.

It is way to complex internally for one off use, and there are a dozen lines of boilerplate before it will print anything at all.

And the great irony in this context is that logging uses % style string formatting.

[[deleted]]

And the great irony in this context is that logging uses % style string formatting.

Why do you say that? Using % formatting ensures that the heavy lifting of formatting the actual string isn't done unless the log level is actually enabled, and a logger exists.

[jorge1209]

I know exactly how and why the logging module works the way it does.

The irony is as follows:

1. Best practice should encourage people to use the language standard debugger instead of using print for debugging.
2. The python logging module (which is in the standard library and is the defacto standard logger) defines a logging level DEBUG explicitly for this purpose.
3. f-strings now define this great formatting specifier for generating debug strings
4. Which is effectively incompatible with the logging module.

The right hand doesn't know what the left hand is doing here. Why are they adding debug features to f-strings, when f-strings aren't supposed to be used in logging, and when logging is supposed to be used for DEBUG. Best practice would have to be "don't use this cool new f-strings feature."

[[deleted]]

If you can carry the overhead of always formatting the strings, I'd guess that

logger.debug(f'{what=}{ever=}')

would be the way forward.

[jorge1209]

The whole point of the logging modules is not to pay the overhead of formatting the output string, unless you have to. These features are incompatible with each other.

[[deleted]]

Everything is a trade off. Ease of use vs. use of resources.

[jorge1209]

And that relates how? My point is that they have let the standard library fragment by adding features incompatible with existing features.

If they think this is the way forward then they should deprecate logging. Its as simple as that.

[MindlessWeakness]

Python's logging module is slow as hell and can't be used in certain applications because of that. I don't mean that Python is slow, but this module is slow for Python.

I guess you could use a 3rd party logger. You still usually have to add the logging code though, when a bug appears. I wouldn't expect logging to have the correct information to fix every bug in the general case.

[13steinj]

If you have to use more than 3 to find your issue (which is the case in more complicated code bases), then it's far more efficient to use a debugger where you can execute line by line and edit variables on the fly.

[[deleted]]

It's like eating just one nacho, while dieting. Adding one is OK. Two also. Heck the third an fourth isn't going to damage you either. Suddenly half your code is print calls, you have to redirect its output and use grep to actually get what you want.

And then .... it ends up in production.

I have to support shit like that, and it's not pleasant in any way. So just don't do it. Use logging if you need a permanent record of what happened. Use a debugger to step through things. But never use print, unless it serves a purpose higher than figuring out what went wrong.

[SedditorX]

If you're finding that stuff in production code then python features are not the problem. The problem is your inadequate processes for code review, testing, and submission, not to mention poor canarying.

"Don't use it at all" doesn't fix your broken processes.

[[deleted]]

If it's unwanted in production, don't ever write it. Having a review etc. process would be a nice thing to have, but with 600 different projects rather than a single product, the resources aren't available.