classification
Title: Handler.close is not called in subclass while Logger.removeHandler is called
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Shufla, r.david.murray, vinay.sajip
Priority: normal Keywords:

Created on 2010-11-19 17:31 by Shufla, last changed 2010-11-20 14:33 by vinay.sajip. This issue is now closed.

Files
File name Uploaded Description Edit
checker.py Shufla, 2010-11-19 17:31 code snippet showing
checkersimple.py Shufla, 2010-11-19 17:36 Simpler version, just add and remove handler
checkerkeyint.py Shufla, 2010-11-19 17:36 Snippet with not catched exception, which works on >=2.7
Messages (5)
msg121554 - (view) Author: Łukasz Nowak (Shufla) Date: 2010-11-19 17:31
Attached file produces output in MyHandler.close on python2.6.6, which is expected.

But on python 2.7 and 2.7.1rc1 it produces nothing, so my handler's close method is not called.
msg121555 - (view) Author: Łukasz Nowak (Shufla) Date: 2010-11-19 17:36
Attached simpler version of checker.
msg121556 - (view) Author: Łukasz Nowak (Shufla) Date: 2010-11-19 17:36
Another snippet, which *WORKS* on python>=2.7, non catched exception is raised.
msg121562 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-11-19 20:02
I doubt that close is ever called when removehandler is called.  That doesn't strike me as sensible semantics.  I suspect that what is happening is that in 2.6 calling removehandler removed all references to the handler, and python's garbage collection called the close method during cleanup.  In 2.7 something is probably still holding a reference; I know Vinay made a number of changes in how handlers are handled in 2.7/3.2.

I think Vinay will want to take a look since (assuming I am correct) the holding of the reference may be a bug, so I'm adding him to nosy.

However, you shouldn't depend on close getting called after the removehandler, since not all Python implementations do garbage collection/cleanup in the same way.  You should always explicitly call close when you are done with a resource.

Finally, I don't understand the point of your third example (but I haven't run it).
msg121655 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2010-11-20 14:33
The reason for this behaviour is as follows: the internal list of handlers now uses weak references, see

http://bugs.python.org/issue6615#msg95691

If there are no references to a handler, it can disappear at any time: and if it does, then it won't get closed at shutdown.

If there are references to it, then the shutdown code will close all handlers on application exit.

So: either leave references to your handlers, or close them when you're done with them, or add a __del__() which will call close() when the handler is garbage collected.

BTW removeHandler() does not call close(), and never has - these are two distinct operations.

It wouldn't be right for the logging package to automatically call close() on handlers, except at application exit - where the main reason for doing so is to flush any pending output and release any resources used by the handler.

Note that adding a __del__(self): self.close() method to MyHandler results in the close() being called [during garbage collection].
History
Date User Action Args
2010-11-20 14:33:38vinay.sajipsetstatus: open -> closed
resolution: not a bug
messages: + msg121655
2010-11-19 20:02:17r.david.murraysetnosy: + r.david.murray, vinay.sajip
messages: + msg121562
2010-11-19 17:36:56Shuflasetfiles: + checkerkeyint.py

messages: + msg121556
2010-11-19 17:36:05Shuflasetfiles: + checkersimple.py

messages: + msg121555
2010-11-19 17:31:59Shuflacreate