Currently, calling os.path.exists on a path which contains NUL characters behaves consistently with most file-system calls by throwing an exception:

>>> os.path.exists('\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/genericpath.py", line 19, in exists
    os.stat(path)
ValueError: embedded null byte

However, os.path.exists is supposed to be a predicate returning whether there exists a file named by the path; it does not specify any particular method or system call for doing the test, and so reflecting the behavior of the underlying syscall used is not obviously desirable. A path containing an embedded NUL character simply cannot name an existing file, and therefore os.path.exists should return False for such a path.

Raising in case no valid path is passed seems fine to me. There are other cases where it fails:

python3 -c "import os; os.path.exists('\ud83d')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/genericpath.py", line 19, in exists
    os.stat(path)
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud83d' in position 0: surrogates not allowed


LANG=C python3 -c "import os; os.path.exists('\xff')"       ~
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/genericpath.py", line 19, in exists
    os.stat(path)
UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 0: ordinal not in range(128)

> A path containing an embedded NUL character simply cannot name an existing file, and therefore os.path.exists should return False for such a path.

I disagree. Python doesn't call the syscall and so must raise a different exception.

You must not pass a path with embedded NULL character/byte. That's all.

Write your own wrapper to os.path.exists() if you want to a different behaviour.