[Python-Dev] PEP 446: Open issues/questions (original) (raw)
Charles-François Natali cf.natali at gmail.com
Sun Jul 28 12🔞55 CEST 2013
- Previous message: [Python-Dev] PEP 446: Open issues/questions
- Next message: [Python-Dev] PEP 446: Open issues/questions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2013/7/28 Antoine Pitrou <solipsis at pitrou.net>:
(C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr) differently? For example, os.dup2(fd, 0) should make the file descriptor 0 (stdin) inheritable or non-inheritable? On Windows, os.setinheritable(fd, False) fails (error 87, invalid argument) on standard streams (0, 1, 2) and copies of the standard streams (created by os.dup()). I have been advocating for that, but I now realize that special-casing these three descriptors in a myriad of fd-creating functions isn't very attractive. (if a standard stream fd has been closed, any fd-creating function can re-create that fd: including socket.socket(), etc.) So perhaps only the original standard streams should be left inheritable?
Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to a log file, a socket...) will likely break a lot of code, e.g. code using os.system(), or code calling exec manually (and I'm sure there's a bunch of it).
Also, it'll be puzzling to have syscalls automatically set the cloexec flag. I guess a lot of people doing system programming with Python will get bitten, but that's a discussion we already had months ago...
cf
- Previous message: [Python-Dev] PEP 446: Open issues/questions
- Next message: [Python-Dev] PEP 446: Open issues/questions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]