classification
Title: HTTPServer server.py assumes sys.stderr != None
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: Mariatta, grismar, gvanrossum, orsenthil, r.david.murray
Priority: normal Keywords: easy, needs review, patch

Created on 2016-09-28 07:08 by grismar, last changed 2016-10-02 12:19 by grismar. This issue is now closed.

Files
File name Uploaded Description Edit
issue28294.patch Mariatta, 2016-09-30 05:37 review
Messages (11)
msg277593 - (view) Author: Jaap van der Velde (grismar) Date: 2016-09-28 07:08
On line 556 of server.py, the sys.stderr.write assumes that sys.stderr is assigned and not None.

However, when developing Windows services using the pypiwin32 library (as an example), sys.stderr == None

A workaround is to override the log_message method of the BaseHTTPRequestHandler, but it seems to me that the method should not assume the availability of stderr?
msg277617 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-09-28 13:42
That would be masking an error, I think.  What might be reasonable would be to convert it to use the logging module in 3.7.
msg277686 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2016-09-29 08:13
Using logging, instead of sys.stderr would be a welcome change in this module.
msg277705 - (view) Author: Mariatta (Mariatta) * (Python committer) Date: 2016-09-29 14:14
I'm interested to work on a patch for this, if no one started yet.
msg277739 - (view) Author: Mariatta (Mariatta) * (Python committer) Date: 2016-09-30 05:37
use the logging module instead of sys.stderr
msg277782 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2016-09-30 23:10
I wonder if we shouldn't close this as "won't fix" and tell the OP to override the log_message() method. It's kind of curious to complain about *this* dependency on sys.stderr existing and working, since there are probably 1000s of other places in the stdlib that also depend on that.
msg277813 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-10-01 13:01
That would be my answer if we aren't switching to logging.  I would consider that an enhancement, but are there reasons to not do that?
msg277822 - (view) Author: Jaap van der Velde (grismar) Date: 2016-10-01 15:22
Closing and not fixing is fair enough - I did not realize that this would be an issue that occurs in many places in stdlib.

I realize this is not a help forum, so I will ask elsewhere to see if there's some way to redirect all of sys.stderr in scenarios like these (running a service), because tracking down an issue like this takes a lot of time and finding the issue buried in a standard library caught me off guard.
msg277823 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2016-10-01 15:35
A problem with switching to logging is the API design.

There are three functions, log_request(), log_error() and
log_message(). The former two call the latter. The API explicitly
encourages overriding log_message() to customize logging. But it has
no way to know whether it's called from log_error(), log_request(), or
directly.

So how is it to choose logging levels? I imagine log_request() should
log at the INFO level, log_error() at the ERROR level, and let's say
that direct calls to log_message() should also log at the INFO level
(from looking at the few calls). So how should log_error() distinguish
itself to log_message() without breaking apps that override the
latter?
msg277834 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-10-02 00:10
OK, lets close this won't fix, then.  Especially since aiohttp does use logging already....

Sorry, Mariatta.  Thanks for the patch, but we aren't going to use it.
msg277888 - (view) Author: Jaap van der Velde (grismar) Date: 2016-10-02 12:19
Breaking the API isn't good, but it will only break if log_message doesn't *receive* all messages, because that's what people who override it count on.

If there's some way of detecting who called log_message, you could use the appropriate log level on logging without compromising the API. But the only way I see without changing the signature of log_message is through inspect functions like getouterframes and that seems way nastier than these functions merit...
History
Date User Action Args
2016-10-02 12:19:57grismarsetmessages: + msg277888
2016-10-02 00:10:14r.david.murraysetstatus: open -> closed
resolution: wont fix
messages: + msg277834

stage: resolved
2016-10-01 15:35:33gvanrossumsetmessages: + msg277823
2016-10-01 15:22:26grismarsetmessages: + msg277822
2016-10-01 13:01:02r.david.murraysetmessages: + msg277813
2016-09-30 23:10:24gvanrossumsetnosy: + gvanrossum
messages: + msg277782
2016-09-30 05:37:11Mariattasetfiles: + issue28294.patch
keywords: + patch
messages: + msg277739
2016-09-29 14:14:44Mariattasetmessages: + msg277705
2016-09-29 08:13:24orsenthilsetkeywords: + easy, needs review
nosy: + orsenthil
messages: + msg277686

2016-09-28 21:11:08Mariattasetnosy: + Mariatta
2016-09-28 13:42:04r.david.murraysetnosy: + r.david.murray
messages: + msg277617
2016-09-28 07:08:24grismarcreate