> So if we expose it and the underlying operating system doesn't support
it, do you want to fallback to fcntl (which wouldb't be atomic
anymore, but let's pretend the GIL protection is enough).

At the beginning, I was convinced that the atomicity was important than the portability. But after having read that even fopen() uses a fallback, it is maybe much more convinient to have a fallback.

For example, it would be annoying that a program works on Linux 2.6.23, but not on Linux 2.6.22 whereas the atomicity is not a must-have. Said differently: the manual fallback described in msg178957 now seems annoying to me :-)

So let's say that a fallback is preferable to improve the portability, but that open(name, "e") would still fail with NotImplementedError if O_CLOEXEC, O_NOINHERIT and fcntl(FD_CLOEXEC) are all missing on a platform. I guess that all platform provide at least one flag/function.

You already implemented a similar fallback for subprocess: use pipe2(O_CLOEXEC) if available, or fallback to pipe()+fcntl(FD_CLOEXEC).

> I'm not sure exactly if this flag is useful enough to be exposed

I would like to benefit of the atomicity feature of O_CLOEXEC, without having to implement myself all the tricky things to check if the platform supports it or not.

O_CLOEXEC solves for example a race condition in tempfile._mkstemp_inner():

            fd = _os.open(file, flags, 0o600)
            _set_cloexec(fd)