[Python-3000] PEP 3138- String representation in Python 3000

Atsuo Ishimoto ishimoto at gembook.org
Tue May 6 15:55:48 CEST 2008


(I changed subject)

Thank you for your comment.

On Tue, May 6, 2008 at 8:45 PM, M.-A. Lemburg <mal at egenix.com> wrote:

>  For sys.stdout this doesn't make sense at all, since it hides encoding
>  errors for all applications using sys.stdout as piping mechanism.
>  -1 on that.

You can raise UnicodeEncodigError for encoding errors if you want, by
setting sys.stdout's error-handler to `strict`.

>
>  Both are really way beyond the scope of the PEP and I don't
>  really see the need for them.

Even though this PEP was rejected, I'll still propose to change
default error-handler for sys.stdout and for sys.stderr to
'backslashreplace'. For Python 2, 'strict' error-handler is acceptable
because most of text data are 8-bit string, but for Py3K, raising
exceptions when the printed text contains a character not supported by
console is annoying.

>  They also don't cover the cases
>  where you write the repr() to a log file, some stream or syslog.

Sure. I missed some cases, such as cgitb module or logging module.
I'll investigate them later. If you have another candidate, please let
me know.

> > - Characters defined in the Unicode character database as
[snip]
>
>  This is all very nice, but if that means that the whole Unicode
>  database has to be loaded every time the interpreter starts up
>  as you indicated on the ticket, them I'm firmly -1 against that.

I changed a patch to add a flag to the _PyUnicode_TypeRecords table,
so the Unicode database is not loaded at stat up.

>
>  I proposed to make the Unicode repr() output a regular encoding
>  that's being implemented by a codec. You could then easily
>  change the encoding to whatever you need for your application
>  or console.

I think global setting is not flexible enough. And I see no benefit to
customizable repr() except to keep compatible with Python 2, but I
think it is easy to migrate the existing code to the Py3k.


More information about the Python-3000 mailing list