[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > IMHO nobody should ever register StreamHandler with sys.stderr because you > cannot be sure has someone intercepted it or not. There's a strong > convention that sys.__stderr__ should not be intercepted so using it is safe. Actually, I believe it is reasonabl

[issue6333] logging: ValueError: I/O operation on closed file

Pekka Klärck added the comment: @vinay.sajip the problem is that many tools that don't do anything with logging module intercept sys.stdout and sys.stderr. Such tools typically aren't even aware of libraries they use (or test) using logging and much less about them registering StreamHandler u

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: Re. the fix to #9501, the swallowing of exceptions was done for specific reasons noted in the comments in the exception clause which does the swallowing. This only happens during application shutdown - not all ValueErrors on flush() or close() are swallowed. In

[issue6333] logging: ValueError: I/O operation on closed file

Pekka Klärck added the comment: The same problem that caused problems to py.test caused problems also to Robot Framework: http://code.google.com/p/robotframework/issues/detail?id=1079 I was surprised to notice this issue was closed as invalid although the problem didn't occur with Python 2.7

[issue6333] logging: ValueError: I/O operation on closed file

holger krekel added the comment: Actually py.test catches stdout separately for setup and for the test code. Moreover, functional or integration test code (py.test is not only for unittests) can easily trigger some implicit logging-module usage which cannot eaysily be factored into a testcase-s

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > Are you suggesting that the ownership of `sys.stderr` belongs to the > logging module once logging.basicConfig (that initializes a > StreamHandler with stderr) is called? > That no other module/library is to close sys.stderr even though they > created it (sys.__

[issue6333] logging: ValueError: I/O operation on closed file

Changes by Vinay Sajip : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/optio

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > Are you suggesting that the ownership of `sys.stderr` belongs to the > logging module once logging.basicConfig (that initializes a > StreamHandler with stderr) is called? > That no other module/library is to close sys.stderr even though they > created it (sys.__

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: On Thu, 09 Jul 2009 16:43:49 -0700, Vinay Sajip wrote: > Vinay Sajip added the comment: > >> However, sys.stdout|err can be assigned to some thing else >> (eg: py.test assigning it to an open file object) .. in which case it >> is legitimate to handle (cl

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > However, sys.stdout|err can be assigned to some thing else > (eg: py.test assigning it to an open file object) .. in which case it > is legitimate to handle (close) such objects (handles) by who > created it (py.test). @Sridhar: I disagree. Creation is not owne

[issue6333] logging: ValueError: I/O operation on closed file

Changes by Vinay Sajip : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/optio

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: > See my comments about your ConsoleHandler recipe(s) on issue6345 Correction: issue6435 -- ___ Python tracker ___

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: On Thu, 09 Jul 2009 06:48:28 -0700, Vinay Sajip wrote: > It should be understood that if a stream is passed to a StreamHandler, > the ownership of that stream is passed as well, so closing the handler > rather than the underlying stream is the right thin

[issue6333] logging: ValueError: I/O operation on closed file

holger krekel added the comment: To recap the use case: stdout is redirected during a test function run which might trigger arbitrary usage of logging-functionality. Not closing the temporary file would mean that there could be as many open files as there are test functions - or one needs to re

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > Is it a problem to have the logging module be a bit more defensive and > only try a flush/close if the stream isn't already closed? Not particularly, but it would be better if the following approach were taken: import logging import StringIO stream = StringIO.S

[issue6333] logging: ValueError: I/O operation on closed file

holger krekel added the comment: I think the issue is unrelated to py.test - it just presents a use case as it wants to run 1000's of tests and capture stdout/stderr per each test function, cannot guess about a test's logging-usage yet wants to minimize memory/resource usage and close any tempor

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > Shouldn't the logging module be reliable in such cases? It tries to be, but it's neither omnipotent nor omniscient. It doesn't expect streams which it's using to be closed out from under it. See my comments about your ConsoleHandler recipe(s) on issue6345. Sor

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: Perhaps there is an issue with py.test. My understanding is that: if the logging module is designed to let users implement their own custom handlers (like I did with ConsoleHandler), is it not expected that they may do whatever they want with it includin

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: Perhaps it's a py.test issue. Have you tried with unittest and nose? Remember, py.test has had little love for a while and so perhaps has a few rougher edges (though I hear in the blogosphere that the project may be rejuvenated shortly). -- __

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: Note: It appears that py.test assigns a temporary file to sys.std[out| err]. -- ___ Python tracker ___ _

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: I have attached a script that repros this bug. Run it using py.test (instructions inside the file). Workaround is by uncommenting the last few lines ('flush' method). -- Added file: http://bugs.python.org/file14474/issue6333repro.py _

[issue6333] logging: ValueError: I/O operation on closed file

Changes by Ezio Melotti : -- priority: -> normal stage: -> test needed status: pending -> open versions: +Python 2.7 -Python 2.6 ___ Python tracker ___ _

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: Can you submit a short script which demonstrates the bug? Your fix is unfortunately not suitable to use as-is, since the StreamHandler operates on file-like objects, and these are not guaranteed to have the "closed" attribute. -- assignee: -> vsajip nosy:

[issue6333] logging: ValueError: I/O operation on closed file

Sridhar Ratnakumar added the comment: BTW, this only happens when running the tests via py.test - http:// pytest.org ... perhaps threading/multiprocess issue. -- ___ Python tracker _

[issue6333] logging: ValueError: I/O operation on closed file

New submission from Sridhar Ratnakumar : The logging module has a bug that tries to call `flush' on a closed file handle (sys.std[out|err] to be specific). This bug was introduced by ConsoleHandler as defined in http://code.activestate.com/ recipes/576819/ The fix is simple: change definition