>> It has to be a ValueError since the error is an invalid 
>> parameter at the Python level.
>
> How does the first follow from the second?

I only meant that, as an honest error, it has to be ValueError. I didn't think about raising a fake OSError.

Note that I didn't say the ValueError shouldn't be ignored by os.path.exists (et al). In the spirit of the current function, it probably should be ignored. For example, it returns False for paths that exist but are inaccessible. 

> I don't believe there is any good reason for singling out NULs 
> for a different exception from other invalid file names 
> like ">" on NTFS.
>
> This ought to be an OSError for functions like os.stat and False 
> for os.path.exists, as Jython does.

Python can't pass a string that contains NUL characters to POSIX and Windows APIs that use null-terminated strings. That would yield wildly unpredictable results. We need this to be a reliable error. So for the low-level file I/O functions to return an OSError here, it would have to be a bit of a lie (i.e. an 'OS' error without making a system call and without an `errno` and/or `winerror` value). Maybe it could raise an InvalidFilename subclass of OSError. This could even handle some actual OS errors such as POSIX ENAMETOOLONG and Windows ERROR_INVALID_NAME, ERROR_BAD_PATHNAME, and ERROR_FILENAME_EXCED_RANGE.