Title: logging.handlers.HTTPHandler.setFormatter() has no effect
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: bk2zsto, python-dev, vinay.sajip
Priority: normal Keywords: patch

Created on 2014-05-29 20:43 by bk2zsto, last changed 2014-05-30 18:05 by python-dev. This issue is now closed.

File name Uploaded Description Edit
logging.handlers.txt.patch bk2zsto, 2014-05-30 14:19 Proposed doc patch: alert users to lack of formatting functions
Messages (5)
msg219365 - (view) Author: Bikram Zesto II (bk2zsto) Date: 2014-05-29 20:43
HTTPHandler instance will assign a Formatter to format() but emit() never calls self.format(record) so it has no effect. I know mapLogRecord() does something like this now but would like to reuse Formatters across Handlers instead of subclassing HTTPHandler just for HTTP logging.

Does it make sense to assign mapLogRecord by default to self.format but allow it to be over-ridden like other Handlers?
msg219372 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2014-05-29 22:27
HTTPHandler doesn't exactly format text for output - it encodes the LogRecord fields into an HTTP GET or POST request, and sends that request to a web server. Since this "formatting" is determined by the HTTP protocol, it is not possible to share it with formatting for other destinations (like console or file).

I don't think a patch which somehow shoehorns a Formatter into mapLogRecord() will be acceptable, both for reasons of backward compatibility and also because formatting in general is not the same as encoding for HTTP, and trying to push the two things together seems kludgy. I advise you to subclass HttpHandler if its default behaviour doesn't work for you. After all, that's why we have classes in Python :-)
msg219390 - (view) Author: Bikram Zesto II (bk2zsto) Date: 2014-05-30 14:19
I see what you are saying about implementation kludginess and will likely subclass just to get my app done.

On the other hand, I think the POLA(stonishment) violation of ignoring format-related configuration of the Handler (even tho it is a subclass) matters too :-)

Was not thinking a Formatter should be put _into_ mapLogRecord. More like idly wondering if mapLogRecord could be implemented as a Formatter. If this sounds like a non-kludge you would be interested in I can work on that. Added benefit being that users could override without subclassing.

Maybe this is more like a documentation issue (since there is no indication that HTTPHandler does not/cannot use a Formatter like other of Handlers?
msg219400 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2014-05-30 16:29
As far as POLA is concerned, IMO serializing to the HTTP request format isn't really a text formatting operation in the same way as for most other handlers. The point is, even if you could have a Formatter handle the operation, you can't usefully share this Formatter with other handlers (which you refer to in your initial post), unless you really want to have format lines such as a=b&c=d&e=f output to console or file, say - which is unlikely to be a common requirement.

I don't expect to make any changes in this area - as I mentioned earlier, because (a) backward compatibility and (b) IMO it will surprise more people than the current approach (IIRC no one else has raised this or a similar issue in the 10+ years that logging has been in Python).

BTW, I am happy to update the documentation for HTTPHandler to indicate that it can't sensibly use a Formatter. I'll do this soon, and that change will close this issue.
msg219408 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-05-30 18:05
New changeset e5373bfbe76b by Vinay Sajip in branch '2.7':
Issue #21608: Updated HTTPHandler documentation.

New changeset 220bed23696e by Vinay Sajip in branch '3.4':
Issue #21608: Updated HTTPHandler documentation.

New changeset 69011f6ce573 by Vinay Sajip in branch 'default':
Closes #21608: Merged documentation update from 3.4.
Date User Action Args
2014-05-30 18:05:56python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg219408

resolution: not a bug -> fixed
stage: resolved
2014-05-30 16:29:55vinay.sajipsetmessages: + msg219400
2014-05-30 14:19:04bk2zstosetfiles: + logging.handlers.txt.patch
keywords: + patch
status: pending -> open
messages: + msg219390
2014-05-29 22:27:55vinay.sajipsetstatus: open -> pending
resolution: not a bug
messages: + msg219372
2014-05-29 22:16:50berker.peksagsetnosy: + vinay.sajip
2014-05-29 20:43:15bk2zstocreate