[Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces (original) (raw)

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