[Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

Michael Urman murman at gmail.com
Sat Apr 25 18:48:21 CEST 2009

On Sat, Apr 25, 2009 at 11:33, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> If the user has the locale setup in way that matches his keyboard,
> it should work all fine - and will already, even without the PEP.
> If the user enters a character that doesn't directly map to a
> good file name, you get an exception, and have to tell the user
> to pick a different filename.

This sound good so far - the 90% (or higher) case is still clean.

> Notice that it may fail at several layers:
> - it may be that characters entered are not supported in what
>  Python choses as the file system encoding.
> - it may be that the characters are not supported by the file
>  system, e.g. leading spaces in Win32.
> - it may be that the file cannot be renamed because the target
>  name already exists.
> In all these cases, the application has to ask the user to
> reconsider; for at least the last case, it should be prepared
> to do that, anyway (there is also the case where renaming fails
> because of lack of permissions; in that case, picking a different
> file name won't help).

This argument sounds good to me too. How will we communicate to
developers what new exception might occur where? It would be a shame
to have a solid application developed under Windows start raising
encoding exceptions on linux. Would the encoding error get mapped to
an IOError for all file APIs that do this encoding?

Michael Urman

More information about the Python-Dev mailing list