Re: [Python-ideas] Adding an 'errors' argument to print
print(msg) calls sys.stdout.write(msg): write() expects text, not bytes. I dislike the idea of putting encoding options in print. It's too specific. What if tomorrow you replace print() with file.write()? Do you want to add errors there too? No, it's better to write own formatter function as shown in a previous email. Victor Le 25 mars 2017 8:50 PM, "Michel Desmoulin" <desmoulinmichel@gmail.com> a écrit : Le 24/03/2017 à 17:37, Victor Stinner a écrit :
This is not the same. You may want to locally apply "errors=replace" and not the whole program. Indeed, this can silence encoding problems. So I would probably never set in to errors at dev time except for the few places where I know I can explicitly silence errors. I quite like this print(errors="replace|ignore"). This is not going to cause any trouble, and can only help. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 26 March 2017 at 18:31, Victor Stinner <victor.stinner@gmail.com> wrote:
While I agree with that, folks that are thinking in terms of errors handlers for str.encode may not immediately jump to using the `ascii()` builtin or the "%a" or "!a" format specifiers, and if you don't use those existing tools, you have the hassle of deciding where to put your custom helper function. Perhaps it would be worth noting in the table of error handlers at https://docs.python.org/3/library/codecs.html#error-handlers that backslashreplace is used by the `ascii()` builtin and the associated format specifiers, as well as noting the format specifiers in the documentation of the builtin function? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
FWIW, using the ascii function does have the problem that Unicose characters will be escaped, even if the terminal could have handled them perfectly fine. -- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com On Mar 26, 2017 9:07 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 26Mar2017 0707, Nick Coghlan wrote:
backslashreplace is also the default errors for stderr, which is arguably the right target for debugging output. Perhaps what we really want is a shorter way to send output to stderr? Though I guess it's an easy to invent one-liner, once you know about the difference:
printe = partial(print, file=sys.stderr)
Also worth noting that Python 3.6 supports Unicode characters on the console by default on Windows. So unless sys.stdout was manually constructed (a possibility, given this was a GUI app, though I designed the change such that `open("CON", "w")` would get it right), there wouldn't have been an encoding issue in the first place. Cheers, Steve
On 27 March 2017 at 13:10, Steve Dower <steve.dower@python.org> wrote:
If there was a printerror builtin that used sys.stderr as its default output stream, it could also special case BaseException instances to show their traceback. At the moment, we do force people to learn a few additional concepts in order to do error display "right": - processes have two standard output streams, stdout and stderr - Python makes those available in the sys module - the print() builtin function lets you specify a stream with "file" - so errors should be printed with "print(arg, file=sys.stderr)" - to get exception tracebacks like those at the interactive prompt, look at the traceback module As opposed to "for normal output, use 'print', for error output, use 'printerror', for temporary debugging output also use 'printerror', otherwise use the logging module". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Le 26/03/2017 à 10:31, Victor Stinner a écrit :
print(msg) calls sys.stdout.write(msg): write() expects text, not bytes.
What you are saying right now is that the API is not granular enough to just add a parameter. Not that it can't be done. It just mean we need to expose stdout.write() encoding behavior.
You would have to rewrite all your calls anyway, because print() call str() on things and accept already many parameters while file.write() doesn't.
No, it's better to write own formatter function as shown in a previous email.
print(encoding) is short, easy to use, unobtrusive and will be used ponctually. How is that using your own formatter function better ?
On Mon, Mar 27, 2017 at 5:22 AM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
You can easily make a wrapper around print(), though. For example, suppose you want a timestamped log file as well as the console: from builtins import print as pront # mess with people @functools.wraps(pront) def print(*a, **kw): if "file" not in kw: logging.info(kw.get("sep", " ").join(a)) return pront(*a, **kw) Now what happens if you add the errors handler? Does this function need to handle that somehow? ChrisA
On 26 March 2017 at 18:31, Victor Stinner <victor.stinner@gmail.com> wrote:
While I agree with that, folks that are thinking in terms of errors handlers for str.encode may not immediately jump to using the `ascii()` builtin or the "%a" or "!a" format specifiers, and if you don't use those existing tools, you have the hassle of deciding where to put your custom helper function. Perhaps it would be worth noting in the table of error handlers at https://docs.python.org/3/library/codecs.html#error-handlers that backslashreplace is used by the `ascii()` builtin and the associated format specifiers, as well as noting the format specifiers in the documentation of the builtin function? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
FWIW, using the ascii function does have the problem that Unicose characters will be escaped, even if the terminal could have handled them perfectly fine. -- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com On Mar 26, 2017 9:07 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 26Mar2017 0707, Nick Coghlan wrote:
backslashreplace is also the default errors for stderr, which is arguably the right target for debugging output. Perhaps what we really want is a shorter way to send output to stderr? Though I guess it's an easy to invent one-liner, once you know about the difference:
printe = partial(print, file=sys.stderr)
Also worth noting that Python 3.6 supports Unicode characters on the console by default on Windows. So unless sys.stdout was manually constructed (a possibility, given this was a GUI app, though I designed the change such that `open("CON", "w")` would get it right), there wouldn't have been an encoding issue in the first place. Cheers, Steve
On 27 March 2017 at 13:10, Steve Dower <steve.dower@python.org> wrote:
If there was a printerror builtin that used sys.stderr as its default output stream, it could also special case BaseException instances to show their traceback. At the moment, we do force people to learn a few additional concepts in order to do error display "right": - processes have two standard output streams, stdout and stderr - Python makes those available in the sys module - the print() builtin function lets you specify a stream with "file" - so errors should be printed with "print(arg, file=sys.stderr)" - to get exception tracebacks like those at the interactive prompt, look at the traceback module As opposed to "for normal output, use 'print', for error output, use 'printerror', for temporary debugging output also use 'printerror', otherwise use the logging module". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Le 26/03/2017 à 10:31, Victor Stinner a écrit :
print(msg) calls sys.stdout.write(msg): write() expects text, not bytes.
What you are saying right now is that the API is not granular enough to just add a parameter. Not that it can't be done. It just mean we need to expose stdout.write() encoding behavior.
You would have to rewrite all your calls anyway, because print() call str() on things and accept already many parameters while file.write() doesn't.
No, it's better to write own formatter function as shown in a previous email.
print(encoding) is short, easy to use, unobtrusive and will be used ponctually. How is that using your own formatter function better ?
On Mon, Mar 27, 2017 at 5:22 AM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
You can easily make a wrapper around print(), though. For example, suppose you want a timestamped log file as well as the console: from builtins import print as pront # mess with people @functools.wraps(pront) def print(*a, **kw): if "file" not in kw: logging.info(kw.get("sep", " ").join(a)) return pront(*a, **kw) Now what happens if you add the errors handler? Does this function need to handle that somehow? ChrisA
Yes Python is turing complete, there is always a solution to everything. You can also do decorators with func = wrapper(func) instead of @wrapper, no need for a new syntax. Le 26/03/2017 à 20:42, Chris Angelico a écrit :
participants (6)
-
Chris Angelico -
Michel Desmoulin -
Nick Coghlan -
Ryan Gonzalez -
Steve Dower -
Victor Stinner