New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stdlib logging references sys.error on import #73
Comments
Scattershot of questions:
|
shutdown snippet for py34-37 try:
logging.config._clearExistingHandlers()
except AttributeError: # pragma Python 3.6,3.7: no cover
logging._handlers.clear()
logging.shutdown(logging._handlerList[:])
del logging._handlerList[:]
try:
logging.Logger.manager._clear_cache()
except AttributeError: # pragma Python 3.7: no cover
logging.Logger.root = logging.root = logging.RootLogger(
logging.WARNING)
logging.Logger.manager = logging.Manager(logging.Logger.root) |
Any If we The "400" isnt so scary as many of them are only using the streams. The problem is stored references to the streams, especially references created a module import (class creation) phase. This includes any time I havent scanned the C portion, so I dont know the size of the problem there. Rather than finding them all, which would still only encompass the stdlib, I think we need to first focus on detecting the problem (and issuing warnings, or raising exceptions, etc). One way that might work is for the streams pushed into |
Technically this is post-existing stream states in the case of |
If my mental model of Python name assignment is correct, I suspect there's not any way to invisibly "intercept" assignments to our mocked objects, such that we could track such assignments and then silently "re-target" the assignments once we're ready to The GC has to know both ends of assignments in order to detect cycles...could we hijack that machinery somehow? [...looks...] Looks like |
But -- what if we added a toggle flag to our object, default to Could foul some |
As special case of #71 , and likely to be one of several cases, stdlib
logging
creates a reference to sys.error on import. As a result the following fairly common scenario of using amain()
to test a cli without subprocesses fails if logging is first imported within the context:After the context handler exits, the wrapper streams are closed, and the logging is still using them.
Easy solution: stdio_mgr imports
logging
, like we would need to for #43Even the following doesnt dislodge the problem:
To clear it properly we need to do:
or the following also seems to work
We can hide that logging cleanup inside of StdioManager.
It also works when
import colorama
is added to that mixture, but I do not feel comfortable that it is solved.Thankfully there doesnt seem to be too many references to sys.std* in the stdlib, so we might be able to check and workaround them all, whenever feasible and appropriate.
The text was updated successfully, but these errors were encountered: