Victor,
PEP 446 mentions that a cloexec flag gets added to os.open. This API already has a way to specify this: the O_CLOEXEC bit in the flags argument. A new cloexec parameter is nicely consistent with the other APIs, but introcudes a second way to set that flag.
What will the following calls do?:
os.open(path, os.O_RDONLY|os.O_CLOEXEC, cloexec=False)
os.open(path, os.O_RDONLY, cloexec=True)
The PEP doesn't specify this, but the implementation for PEP 443 in issue 17036 basicly ignores the cloexec argument in the first call and adds O_CLOEXEC in the second call. That can lead to confusing behavior when the flags argument to os.open is passed from elsewhere (e.g. a wrapper around os.open that passes in arguments and just overrides the cloexec argument).
It might be better to just drop the cloexec flag to os.open and make os.O_CLOEXEC an alias for os.O_NOINHERIT on Windows.
Ronald
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4