[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Nick Coghlan added the comment: Actually, I take it back. The default state of logging appears to do the right thing with no special handler installed - both the .critical() and .exception() messages are written out to stderr by default, so the futures tests pass even after Brian's patch is a

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Antoine Pitrou added the comment: > Wow, I didn't realize that's how logging worked. My understanding was > a module should just get a logger and log messages, and if the > application didn't do any setup beforehand, the first logging call > would cause messages to be written to stdout (or stde

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

R. David Murray added the comment: Wow, I didn't realize that's how logging worked. My understanding was a module should just get a logger and log messages, and if the application didn't do any setup beforehand, the first logging call would cause messages to be written to stdout (or stderr)

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Antoine Pitrou added the comment: > The problem of avoiding interfering with application level handlers > while having unraisable errors visible by default is probably the > biggest reason past attempts to get the standard library using the > logging module internally haven't gained much tractio

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Nick Coghlan added the comment: For 3.2, writing such errors directly to stderr would be fine (we already do that in other places via PyErr_WriteUnraisable) The test could then be modified to use test.support.captured_output to temporarily replace stderr and look at the output. The problem o

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Brian Quinlan added the comment: I've attached a patch that removes the code that installs a handler to the futures logger. I'm not sure if this is the correct approach though - it means that "impossible" errors will only be reported to the user through a message like "no handler installed f

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Georg Brandl added the comment: What a nice mess :) Raising priority so that this doesn't get overlooked. -- priority: normal -> deferred blocker ___ Python tracker ___ ___

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Nick Coghlan added the comment: This is unrelated to issue 10517 (based on Dave Malcolm's initial investigation, that looks like it may be a genuine problem in multiprocessing) Instead, this relates to a problem in concurrent.futures where it installs a logging *handler* as a side effect of i