Why exception from os.path.exists()?

[Barry Scott]

> On 10 Jun 2018, at 21:10, Chris Angelico <rosuav at gmail.com> wrote:
> 
> On Mon, Jun 11, 2018 at 12:45 AM, Bev in TX <countryone77 at gmail.com> wrote:
>>> * One with an embedded / in the file name
>> 
>> This is easily done in Finder, where I created a folder named "my/slash”.
>> When I list it at the command line in Terminal, this shows up as "my:slash”, with the slash shown as a colon.
>> If I create a file with a colon in its name at the command line, that file name acts the same way:
>> 
>> $ touch ‘my:colon"
>> $ ls
>> my:colon
>> my:slash
>> 
>> In Finder they both display as:
>> my/colon
>> my/slash
>> 
>> However, if you use Finder’s “Copy item as Pathname” option, then you will again see the colon.
>> 
>> /Users/bev/Training/myPython/pygroup/files/my:colon
>> /Users/bev/Training/myPython/pygroup/files/my:slash
>> 
>> But if you paste that folder’s name in Finder’s “Go to Folder” option, it converts it to the following, and goes to that folder:
>> 
>> /Users/bev/Training/myPython/pygroup/files/my/slash/slash
> 
> Can you try creating "spam:ham" and "spam/ham"? If they're both legal,
> I'd like to see what their file names are represented as.

On Classic Mac OS the folder separator was : not /. /usr/bin/ls would be usr:bin:ls for example.

It looks like a hang over from Classic that the macOS Finder maps between : to / for presentation.
In bash you see the ":" in Finder you see a /.

In the Finder attempting to use a : in a filename gets an error message "Name cannot be uses a:b".
In macOS bash you cannot use a / in a filename.

I think what all boils down to this:

Windows, macOS and Linux etc all use a 0 as the end of string marker. (Windows uses 16bit 0 not 8bit 0).
The os file functions call the underlying OS and map its results into successes or exceptions.

The \0 means that the OS functions cannot be passed the data from the user.
Therefore you cannot get an error code from the OS.

All the other file systems rules are checked by the OS itself and any errors are reported to the user as OSError etc.

For example on windows the OS will prevent use '<' in a filename and it is the OS that returned the error.

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> open('a<b', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'a<b'

Where as python reports that its cannot get the OS to work with an embedded NUL like this:

>>> open('a\0b', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: embedded null character
>>>

Singling out os.path.exists as a special case I do think is reasonable.
All functions that take paths need to have a consistent response to data that is impossible to pass to the OS.

When it is impossible to get the OS to see all of the users data I'm not sure what else is reasonable for python
to do then what it already does not NUL.

With the exception that I do not think this is documented and the docs should be fixed.

Barry