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

[Michael Urman]

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