On 1 June 2018 at 13:15, Barry Scott <ba...@barrys-emacs.org> wrote: > I think the reason for the \0 check is that if the string is passed to the > operating system with the \0 you can get surprising results. > > If \0 was not checked for you would be able to get True from: > > os.file.exists('/home\0ignore me') > > This is because a posix system only sees '/home'.
So because the OS API can't handle filenames with \0 in (because that API uses null-terminated strings) Python has to special case its handling of the check. That's fine. > Surely ValueError is reasonable? Well, if the OS API can't handle filenames with embedded \0, we can be sure that such a file doesn't exist - so returning False is reasonable. > Once you know that all of the string you provided is given to the operating > system it can then do whatever checks it sees fit to and return a suitable > result. As the programmer, I don't care. The Python interpreter should take care of that for me, and if I say "does file 'a\0b' exist?" I want an answer. And I don't see how anything other than "no it doesn't" is correct. Python allows strings with embedded \0 characters, so it's possible to express that question in Python - os.path.exists('a\0b'). What can be expressed in terms of the low-level (C-based) operating system API shouldn't be relevant. Disclaimer - the Python "os" module *does* expose low-level OS-dependent functionality, so it's not necessarily reasonable to extend this argument to other functions in os. But it seems like a pretty solid argument in this particular case. > As an aside Windows has lots of special filenames that you have to know about > if you are writting robust file handling. AUX, COM1, \this\is\also\COM1 etc. I don't think that's relevant in this context. Paul -- https://mail.python.org/mailman/listinfo/python-list