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
HTTPServer server.py assumes sys.stderr != None #72481
Comments
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? |
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. |
Using logging, instead of sys.stderr would be a welcome change in this module. |
I'm interested to work on a patch for this, if no one started yet. |
use the logging module instead of sys.stderr |
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. |
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? |
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. |
A problem with switching to logging is the API design. There are three functions, log_request(), log_error() and So how is it to choose logging levels? I imagine log_request() should |
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. |
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... |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: