[Python-Dev] PEP 383 (again)

Thomas Breuel tmbdev at gmail.com
Tue Apr 28 10:37:45 CEST 2009

>    Until it's hard there will be no internationalization. A fact of life,
> damn it. Programmers are lazy, and have many problems to solve.

PEP 383 doesn't make it any easier; it just turns one set of problems into
another.  Actually, it makes it worse, since any problems that show up now
show up far from the source of the problem, and since it can lead to
security problems and/or data loss.

>    And the programmer answers "The program is expected a correct
> environment, good filenames, etc." and closes the issue with the resolution
> "User error, will not fix".

The problem may well be with the program using the wrong encodings or
incorrectly ignoring encoding information.  Furthermore, even if it is user
error, the program needs to validate its inputs and put up a meaningful
error message, not mangle the disk.  To detect such program bugs, it's
important that when Python detects an incorrect encoding that it doesn't
quietly continue with an incorrect string.

Furthermore, if you don't provide clear error messages, it often takes a
significant amount of time for each issue to determine that it is user

>   I am not arguing for or against the PEP in question. Python certainly
> has to have a way to make portable i18n less hard or else the number of
> portable internationalized program will be about zero. What the way should
> be - I don't know.

Returning an error for an incorrect encoding doesn't make
internationalization harder, it makes it easier because it makes debugging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090428/ecbffe57/attachment-0001.htm>

More information about the Python-Dev mailing list