What should go to stdout/stderr and why Python logging write everything to stderr?

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2023-01-03 at 21:24:20 +0000,
c.buhtz at posteo.jp wrote:

> The main question here is why does Python deciecded to make all logs
> go to stderr?

It makes sense to send all logging to one destination, and stderr is
that place.

> Maybe I totally misunderstood the intention of logging.info()?! Isn't
> this the "usual applicaton output"?

Aha.  This seems to be the misconception.  "Usual" in the sense of "the
application is running as usual," but not in the sense of "the output
the users usually see."

Logging is the process where applications write details that ordinarily
aren't visible to the user.  Logs are for forensics, after the fact.
There is an entire universe of software for managing (writing, reading,
archiving, retrieving, searching, etc.) log files.

At my last job, we wrote gigabytes of compressed logs every hour, and
read roughly two or three out of a million entries to track down
questions from our users.  Users wouldn't have understood 99% of what
was in the logs anyway.

I also worked a lot in embedded systems, like telephone switches.  Users
(i.e., the people with the telephones) didn't have access to the
switches, but when things went wrong, I could look at the switches' logs
to get the their view of what happened.

> If not, what messages should go into logging.info()? Can you name me some
> examples?

INFO level messages usually track "regular" happy-path progress through
your application:  reading config files, calculating results, writing
report.  Again, not meant for users (who would have their own progress
meters, textual or graphical), but for tracking down problems when there
are problems.  For one example, the name of the config file, even if you
only tell the users that you found a config file.

HTH