Changes between Version 2 and Version 6 of Ticket #2268


Ignore:
Timestamp:
04/04/2015 09:13:20 PM (5 years ago)
Author:
sebastian
Comment:

I didn't argued against using the logging module. My point just was that I consider the setupStderr() hack harmful. Using the logging module instead writing to sys.stderr directly actually sounds good.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #2268

    • Property Priority changed from Unknown to P3
    • Property Ready set
  • Ticket #2268 – Description

    v2 v6  
    44While this - IMO ugly - hack prevents `UnicodeEncodeError`s when writing `unicode` objects with non-ascii text to stderr, it causes `UnicodeDecodeError`s when you write `str` objects with non-ascii data to stderr. 
    55 
    6 Moreover, the way it's currently implemented doesn't work for WSGI apps running in a server environment, since there is no `sys.stderr`. Unhandled exceptions are logged to `environ["wsgi.errors"]` instead. 
     6Moreover, we have more boilerplate code importing and calling `setupStderr()` than code actually writing to `sys.stderr`. 
    77 
    88=== What to change === 
    9 Remove the `setupStderr()` function. 
     9Remove the `setupStderr()` function and use the `logging` module to log warnings instead.