Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #12431 > unrolled thread

Making `logging.basicConfig` log to *both* `sys.stderr` and `sys.stdout`?

Back to article view | Back to comp.lang.python

Contents

  Making `logging.basicConfig` log to *both* `sys.stderr` and `sys.stdout`? Michel Albert <exhuma@gmail.com> - 2011-08-30 01:53 -0700
    Re: Making `logging.basicConfig` log to *both* `sys.stderr` and `sys.stdout`? Peter Otten <__peter__@web.de> - 2011-08-30 11:45 +0200
      Re: Making `logging.basicConfig` log to *both* `sys.stderr` and `sys.stdout`? Michel Albert <exhuma@gmail.com> - 2011-08-30 04:59 -0700
    Re: Making `logging.basicConfig` log to *both* `sys.stderr` and `sys.stdout`? Vinay Sajip <vinay_sajip@yahoo.co.uk> - 2011-09-02 15:59 -0700

#12431 — Making `logging.basicConfig` log to *both* `sys.stderr` and `sys.stdout`?

Hi,

I use python oftentimes to write automation scripts on Linux servers.
And there's a big pattern in my scripts:

- I *always* use `logging` instead of `print` statements.
- I *always* create two stream handlers. One for `sys.stdout` with
level `INFO` and one for `sys.stderr` with level `WARN`

Well, the levels may variate occasionally, but that's only the rare
exception.

The reason I do this is simple: Most automation tasks are run via
cron. With this setup, I can redirect `stdout` to `/dev/null` and
still receive e-mails if things go wrong.

And having two handlers gives me more flexibility in my scripts. In
one case, I used a different color for error messages for example as
this script is run primarily from the shell and having errors stand
out has proven to be a good thing.

Unfortunately this setup makes `logging.basicConfig` pretty useless.
However, I believe that this is something that more people could
benefit from. I also believe, that it just "makes sense" to send
warnings (and above) to `stderr`, the rest to `stdout`.

So I was thinking: "Why does `logging.basicConfig` not behave that
way".

Naturally, I was thinking of writing a patch against the python
codebase and submit it as a suggestion. But before doing so, I would
like to hear your thoughts on this. Does it make sense to you too or
am I on the wrong track? Are there any downsides I am missing?

[toc] | [next] | [standalone]

#12433

Michel Albert wrote:

> I use python oftentimes to write automation scripts on Linux servers.
> And there's a big pattern in my scripts:
> 
> - I *always* use `logging` instead of `print` statements.
> - I *always* create two stream handlers. One for `sys.stdout` with
> level `INFO` and one for `sys.stderr` with level `WARN`
> 
> Well, the levels may variate occasionally, but that's only the rare
> exception.

How would a call to basicConfig() look like that produces this setup?

[toc] | [prev] | [next] | [standalone]

#12437

On Aug 30, 11:45 am, Peter Otten <__pete...@web.de> wrote:
> Michel Albert wrote:
> > I use python oftentimes to write automation scripts on Linux servers.
> > And there's a big pattern in my scripts:
>
> > - I *always* use `logging` instead of `print` statements.
> > - I *always* create two stream handlers. One for `sys.stdout` with
> > level `INFO` and one for `sys.stderr` with level `WARN`
>
> > Well, the levels may variate occasionally, but that's only the rare
> > exception.
>
> How would a call to basicConfig() look like that produces this setup?

I personally see this happen by default (i.e. no additional
parameters). And in case the `stream` parameter is set, /then/ you
would  send all to that stream only.

In my point of view, the call to `basicConfig` is either something
used in only the most mundane usages of the logging package, or it's
mainly used by people that have not yet grokked the logging package
(correct me if I'm wrong). In both cases, I find it useful to redirect
warnings and errors to `stderr` by default.

However, this would also mean that existing code calling this method
would result in different behavior. But only /slightly/ different.
Meaning, you still see the output on the console as expected. But it
gives you the possibility to use standard shell redirection in a way
that "makes sense".

[toc] | [prev] | [next] | [standalone]

#12680

On Aug 30, 9:53 am, Michel Albert <exh...@gmail.com> wrote:


> Unfortunately this setup makes `logging.basicConfig` pretty useless.
> However, I believe that this is something that more people could
> benefit from. I also believe, that it just "makes sense" to send
> warnings (and above) to `stderr`, the rest to `stdout`.
>
> So I was thinking: "Why does `logging.basicConfig` not behave that
> way".

Because what seems entirely natural and obvious to you might not seem
so for someone else. The API in the stdlib tries to provide baseline
functionality which others can build on. For example, if you always
have a particular pattern which you use, you can always write a
utility function to set things up exactly how you like, and others who
want to set things up differently (for whatever reason) can do the
same thing, without having to come into conflict (if that's not too
strong a word) with views different from their own.

> Naturally, I was thinking of writing a patch against the python
> codebase and submit it as a suggestion. But before doing so, I would
> like to hear your thoughts on this. Does it make sense to you too or
> am I on the wrong track? Are there any downsides I am missing?

Python 2.x is closed to feature changes, and Python 2.7 and Python 3.2
already support flexible configuration using dictConfig() - see

http://docs.python.org/library/logging.config.html#logging.config.dictConfig

Also, Python 3.3 will support passing a list of handlers to
basicConfig(): see

http://plumberjack.blogspot.com/2011/04/added-functionality-for-basicconfig-in.html

which will allow you to do what you want quite easily.

Regards,

Vinay Sajip

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web