Question: Is the text=True|False parameter in mkstemp something Windows specific? I'm sorry that I have to ask, but I'm a UNIX/Linux person. At the low level of file descriptors - where the mkstemp operates - are all files just bytes. I was surprised to see the text= parameter. The only hint I found is a comment in os.open docs:  In particular, on Windows adding O_BINARY is needed to open files in binary mode.   For completness the tempfile.mkstemp docs:  If text is specified and true, the file is opened in text mode. Otherwise, (the default) the file is opened in binary mode.   mkstemp() returns a tuple containing an OS-level handle to an open file (as would be returned by os.open()) and the absolute pathname of that file, in that order.  And an example. It indeed returns a file descriptor and a filename: >>> import tempfile >>> tempfile.mkstemp(text=False) (3, '/tmp/tmp9z8rp2_2') >>> tempfile.mkstemp(text=True) (4, '/tmp/tmpc6z9j2yu') 

Answer: It's a feature of the default C runtime library on Windows. When a file is opened in text mode – not through the Win32 CreateFile() API, but specifically through the POSIX open() API – writes to it will transparently convert LF line-endings to CR+LF (i.e. writing \n will actually write \r\n).  https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/file-handling?view=msvc-170   At the low level of file descriptors - where the mkstemp operates - are all files just bytes  File descriptors are not "low level" when it comes to Windows, though. One important thing about Windows is that it is not a POSIX-like system in the slightest – even though it comes with a C runtime library that provides POSIX-like functionality, a lot of it is emulated in userspace. For example, the "file descriptors" you get from open() are not real and the kernel doesn't know them; it's only the C runtime that maps them to actual OS "file handles" for easier porting of POSIX-like code (see e.g. _get_osfhandle() and _open_osfhandle()). Compare MSVC open() with Win32 CreateFile(). The latter returns you a HANDLE, which indeed works purely with bytes – and is not too different from POSIX file descriptors – but is not quite the same as an ordinary int. (And even that isn't the real system call – the entirety of Win32 is another layer over the "NT native API", e.g. NtCreateFile(), which works with the same file handles but has different semantics when it comes to paths and such.) So with that in mind, you can actually consider POSIX file descriptors on Windows almost as high level as C stdio 'FILE' objects that fopen() would return – or even Python's io.TextIOWrapper objects that open("foo", "w", newline="\r\n") gives you.  Python automatically specifies O_BINARY when necessary, e.g. when opening a file as "rb" it will correctly be in binary mode, but sometimes it's necessary to do that manually (e.g. stdin/out cannot be re-opened and defaults to text mode), which can be done using the msvcrt module: if sys.platform == "win32": import msvcrt msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)  You can also use it to see the underlying file handles of the "file descriptors": >>> a = open("foo.txt", "w") >>> a.fileno() 3 >>> msvcrt.get_osfhandle(3) 1044