On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > I think this is worth keeping, and "I couldn't pass that file name to > the OS" is a different error than "the OS told me the file doesn't > exist", so I think it should be a different exception.
What makes you think that NUL bytes are a fundamental limitation that no OS could every cope with? Classic Mac OS takes file names as Pascal strings, with a length byte and an array of arbitrary bytes, no NUL terminator required. Despite what far too many C programmers appear to believe, NUL-terminated strings are not a fundamental requirement. Navigating Apple's documentation is a nightmare, but I've found the deprecated Carbon file manager APIs. For example, creating a file with PBCreateFileUnicodeSync: https://developer.apple.com/documentation/coreservices/1566896- pbcreatefileunicodesync?language=objc takes a FSRefParam argument: https://developer.apple.com/documentation/coreservices/fsrefparam? language=objc which includes a name field which is a pointer to an array of Unicode characters, and a separate name length. The evidence suggests that using the Carbon APIs, NUL is just another Unicode character. Whatever API replaces Carbon, it will have to deal with file names created under Carbon, and classic Mac, and so likely will support the same. Baking a limitation of some file systems into the high-level interface is simply a *bad idea*. There is no good reason to treat file names containing NUL as special in the API (even if, for implementation reasons, it has to be treated specially in the implementation). How would you feel if there were a whole lot of ignorant Pascal programmers arguing that it was fundamentally impossible for file names to exceed 255 characters, and therefore os.path.exists() out to raise ValueError when passed a file name of 256 characters? "But it is impossible to pass a string of 256 characters to the OS" is no more foolish than "it is impossible to pass a string with an embedded NUL to the OS". Both are implementation details. Neither should be baked into the high-level language as a fundamental requirement. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
