| 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) *  |
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) * |
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) * |
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) * |
Date: 2016-09-30 05:37 |
| use the logging module instead of sys.stderr |
|
|
| msg277782 - (view) |
Author: Guido van Rossum (gvanrossum) * |
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) * |
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) * |
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) * |
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... |
|
|