Hi,
Thanks for the help. I didn’t know about handler.close. (By which I
mean that I used logging without re-reading its documentation, which is
a testimony to its usability :)
The cases you refer to seem to be _set_logger in packaging/run.py
(which appears
not to be used at all - there appear to be no other references to it
in the
code),
Yep, probably dead code. I think that an handler should be defined
only once, in the “if __name__ == '__main__'” block. Am I right? Just
like you don’t call sys.exit from library code (hello optparse!), you
don’t set logging handlers in library code, only in the outmost layer of
the script.
Dispatcher.__init__ in packaging/run.py and
This is the new-fangled command line parser, which can run global
(Python-wide) commands (search, uninstall, etc.) as well as traditional
project-wide commands (build, check, sdist, etc.)
Distribution.parse_command_line in packaging/dist.py.
This is the older command line parser, that can handle only
project-wide commands. I’m not sure the work is finished to integrate
both parsers; my smoke test used to be --help-commands, which can be
hard to run these days.
The problem is that Dispatcher or Distribution get the quiet or verbose
options from the command-line deep in the library code, and want to use
it to configure the log level on the handler, which I’ve just said
should be set up at a much higher level. To solve this, I’m going to
add a *logginghandler* argument to Dispatcher/Distribution; that way,
the creation of the handler will happen only once and at a high level,
but the command-line parsing code will be able to set the log handler
from the command-line arguments. :)
In the second and third cases, can you be sure that only one of these
code paths
will be executed, at most once?
Gut feeling is yes, but we’ve learned not to trust our instinct with
distutils.
In the case of the test support code, I'm not really sure that
LoggingCatcher is
needed. There is already a TestHandler class in test.support which
captures
records in a buffer, and allows flexible matching for assertions, as
described in
distutils used its own log module; this mixin was used to intercept
messages sent with this system. When we migrated to stdlib logging, I
added a todo comment to update the code to use something less kludgy :)
The post you linked to is already in my bookmarks. Note that this
support module also helps with Python 2.4+, so I may have to copy-paste
TestHandler.
So, I will fix the LoggingCatcher mixin to use the much cleaner
addHandler/removeHandler combo (I’ll avoid calling
logging._removeHandlerRef if I don’t have to) and try my idea about the
handler instantiation in the code. Thanks a lot!
Cheers
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
