This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients doughellmann, eric.smith, exarkun, georg.brandl, michael.foord, ncoghlan, pitrou, r.david.murray, theller, vinay.sajip
Date 2009-09-22.19:45:37
SpamBayes Score 8.55474e-09
Marked as misclassified No
Message-id <1253648740.14.0.968096439142.issue6958@psf.upfronthosting.co.za>
In-reply-to
Content
@theller: Although your use case just covers using basicConfig, I can
just see users expecting the same mechanism to invoke configuration
stored in a logging configuration file, which is why I suggested the
config= variant. However, doughellmann raises the valid point of what
the semantics would be if the program you invoke via logging -m does its
own configuration.

With a simple implementation: If a script calls basicConfig after it has
been invoked with logging -m etc. then the basicConfig call won't do
anything, as if the root logger already has some handlers, the call is
essentially a no-op. If the called script loads a configuration file,
that will overwrite the configuration specified via logging -m.

Either way, it's not consistent IMO - sometimes the logging -m
configuration will seem to win, and other times, the called script's
configuration.

Of course, it could be argued that logging -m is intended for scripts
which don't do explicit configuration - I'm not sure of how strong an
argument this is.

Thinking caps on :-)
History
Date User Action Args
2009-09-22 19:45:40vinay.sajipsetrecipients: + vinay.sajip, theller, georg.brandl, exarkun, ncoghlan, pitrou, eric.smith, doughellmann, r.david.murray, michael.foord
2009-09-22 19:45:40vinay.sajipsetmessageid: <1253648740.14.0.968096439142.issue6958@psf.upfronthosting.co.za>
2009-09-22 19:45:38vinay.sajiplinkissue6958 messages
2009-09-22 19:45:38vinay.sajipcreate