[Python-Dev] Problems with regrtest and with logging

[Éric Araujo]

 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