Message93012
@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 :-) |
|
Date |
User |
Action |
Args |
2009-09-22 19:45:40 | vinay.sajip | set | recipients:
+ vinay.sajip, theller, georg.brandl, exarkun, ncoghlan, pitrou, eric.smith, doughellmann, r.david.murray, michael.foord |
2009-09-22 19:45:40 | vinay.sajip | set | messageid: <1253648740.14.0.968096439142.issue6958@psf.upfronthosting.co.za> |
2009-09-22 19:45:38 | vinay.sajip | link | issue6958 messages |
2009-09-22 19:45:38 | vinay.sajip | create | |
|