Why exception from os.path.exists()?

[Steven D'Aprano]

On Mon, 11 Jun 2018 12:31:09 +0200, Peter J. Holzer wrote:

> On 2018-06-11 01:06:37 +0000, Steven D'Aprano wrote:
>> On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote:
> 
> [Note: I was talking about os.stat here, not os.path.exists. I agree
> that os.path.exists (and the other boolean functions) should simply
> return false]

o_O

Well... I don't know what to say. In a thread about os.path.exists, 
you're talking about os.stat. I see. I don't understand why, but if you 
want to derail the thread to discuss something else, okay, I'll play 
along.


[...]
> We are talking about platform-specific code here.

Are we? I thought we were talking about Python and the os module. The 
very first paragraph of the documentation for os says:

    This module provides a portable way of using operating
    system dependent functionality.

https://docs.python.org/3/library/os.html


It also clearly states:

    All functions in this module raise OSError in the case of
    invalid or inaccessible file names and paths, or other
    arguments that have the correct type, but are not accepted
    by the operating system. 

You know... like strings with NUL in them.



> On POSIX systems, there IS NO WAY to pass a
> filename with an embedded NUL byte to the OS.

Mac OS X is certified as POSIX-compliant. As I pointed out in a previous 
email, OS X also provides APIs that are perfectly capable of dealing with 
NULs in file names.

POSIX specifies a *minimum* set of functionality, not a maximum.



> On such systems Python
> MUST NOT simply pass a pointer to the start of the (utf-8 encoded)
> string to the OS, it must take special action. It could fake an ENOENT
> error, but that would be confusing in many situations. Therefore it
> should raise an exception which cannot be confused with an error
> returned from the OS.

I agree that for os.stat, which already raises on error, raising for 
invalid file names is the right thing to do. As stated in the 
documentation, the right exception is an OSError, which matches the 
current behaviour for other impossible and invalid file names:


py> os.stat('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: ''



[...]
>> Baking a limitation of some file systems into the high-level interface
>> is simply a *bad idea*.
> 
> We aren't talking about a high-level interface here.

Yes we are.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson