I think it's should be TypeError as Python 2.7.

The doc https://docs.python.org/3/library/os.path.html
doesn't says it accept file descriptor.


Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.isfile(123)
False
>>> os.path.isfile(2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Dev\Python3\lib\genericpath.py", line 30, in isfile
    st = os.stat(path)
OverflowError: fd is greater than maximum
>>>

Python 3.8.0b1 (tags/v3.8.0b1:3b5deb0116, Jun  4 2019, 19:52:55) [MSC v.1916 64 bit (AMD64)] on win32
>>> import os.path
>>> os.path.isfile(123)
False
>>> os.path.isfile(2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\obj\Windows-Release\38amd64_Release\msi_python\zip_amd64\genericpath.py", line 30, in isfile
OverflowError: fd is greater than maximum
>>>

Python 2.7.16 (v2.7.16:413a49145e, Mar  4 2019, 01:37:19) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.isfile(123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Dev\Python\lib\genericpath.py", line 37, in isfile
    st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, int found
>>>

Integers seems to be accepted, so not a TypeError? Maybe documentation needs some more information. 


Documentation os.path under os.path.exists(path):

Changed in version 3.3: path can now be an integer: True is returned if it is an open file descriptor, False otherwise.


in posixmodule.c:

 * path_converter also optionally accepts signed
 * integers (representing open file descriptors) instead
 * of path strings.


although i dunno how to use then:

$ echo "test" > 123
$ ls -i 123
8012691 123
$ ./python -c "import os.path; print(os.path.isfile(8012691))"
False
$ ./python -c "import os.path; print(os.path.isfile('123'))"
True

You use this by getting the file descriptor/fileno for an open file, and then testing whether it's a file or not:

>>> f=open("python.bat")
>>> f.fileno()
3
>>> import os
>>> os.path.isfile(3)
True

This is very uncommon on Windows to begin with (file descriptors are emulated by the C Runtime for POSIX compatibility), but it is supported.

Enabling Modules/posixmodule.c#L2446 to be able to optionally handle the OverflowError would allow the "exists" type functions to just return False instead of raising, while letting the others continue to raise.

I'm going to mark this as "easy (C)" so that we consider it for sprints. But in principle, I'm okay with returning False for invalid values in exists-type functions rather than raising.

Personally I prefer TypeError. Use file descriptor is rare, I never used it in Python script.
I encountered this because arguments passed in wrong order in my function, then I passed the wrong argument to isfile() without checking.
Make isfile() returns False would make it harder to find bugs in user program.

Please also consider following pieces of code.
They (value of int sub classes) can't be returned by fileno().

Python 3.8.0b1 (tags/v3.8.0b1:3b5deb0116, Jun  4 2019, 19:52:55) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyInt(int):pass
...
>>> a=MyInt(6)
>>> a
6
>>> import os.path
>>> os.path.isfile(a)
False
>>> os.path.isfile(True)
False
>>> os.path.isfile(False)
False
>>>

Hi all, I'm a newcomer interested in doing a small fix. Wondering if anyone's working on this at the moment?

This issue reminds me bpo-33721:

"os.path functions that return a boolean result like exists(), lexists(), isdir(), isfile(), islink(), and ismount() now return False instead of raising ValueError or its subclasses UnicodeEncodeError and UnicodeDecodeError for paths that contain characters or bytes unrepresentable at the OS level. (Contributed by Serhiy Storchaka in bpo-33721.)"

https://docs.python.org/dev/whatsnew/3.8.html#os-path

Hey, I'm not exactly clear what the required fix is here and would appreciate some guidance, is it in the documentation or in the way the error is handled?

I am not sure there is much in common between this and issue33721. There are many ways to get a file path unrepresentable at the OS level. But I do not know any valid case for getting an out-of-range file descriptor. I am not convinced there is a bug here.

Hey, if there is no bug here, could we get this issue closed?
Alternatively, I'd be interested in doing the required change in documentation/error type if that's seen to be the right solution.

Personally, I think returning False instead of raising an error would indeed mask bugs as mentioned by Zufu. As for the error type to be raised, the argument type itself isn't wrong, it's just greater than the maximum so I feel an OverflowError type is right instead of TypeError. So maybe just clearer documentation is needed as suggested by Aldwin and no code change? Just my two cents though.

I'm fine with this been closed.
Maybe it's better to have a RawFd type like Julia:

julia> RawFD
RawFD

julia> typeof(RawFD)
DataType

julia> RawFD(0)
RawFD(0x00000000)

julia> RawFD(0)==0
false

Rust has RawFd as c_int.

I considered this. There is a limited number of functions that can produce RawFD (os.open(), os.dup(), etc), and this is a single source of file descriptors in an isolated program. File descriptors can be inherited by child processes. But there are other methods of interprocess communication, and depending of the serialization method the type of the file descriptor can be lost. So there is a possibility to break existing programs. The transition can be made smooth, with corresponding deprecation period if we decide that the final befit is larger than the transition cost.

In any case this is a large change. It should be discussed on the Python-ideas or Python-Dev mailing lists.