Vinay Sajip <vinay_sa...@yahoo.co.uk> added the comment: @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 :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6958> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
