> That could always be overcome by passing close_fds=False explicitly to
> subprocess from my code, though, right? I'm not doing that now, but then I'm
> not
> using the esoteric options in python-gnupg code, either.
You could do that, or better explicitly support this option, and only
specify this file descriptor in subprocess.Popen keep_fds argument.
> My point was that the GnuPG usage looked like an example where fds other than
> 0, 1 and 2 might be used by design in not-uncommonly-used programs. From a
> discussion I had with Barry Warsaw a while ago, I seem to remember that there
> was other software which relied on these features. See [1] for details.
Yes, it might be used. But I maintain that it should be really rare,
and even if it's not, since the "official" way to launch subprocesses
is through the subprocess module, FDs > 2 are already closed by
default since Python 3.2. And the failure will be immediate and
obvious (EBADF).
Note that I admit I may be completely wrong, that's why I suggested to
Victor to bring this up on python-dev to gather as much feedback as
possible. Something saying like "we never ever break backward
compatibility intentionally, even in corner cases" or "this would
break POSIX semantics" would be enough (but OTOH, the subprocess
change did break those hypothetical rules).
Another pet peeve of mine is the non-handling of EINTR by low-level
syscall wrappers, which results in code like this spread all over the
stdlib and user code:
while True:
try:
return syscall(...)
except OSError as e:
if e.errno =!= errno.EINTR:
raise
(and if it's select()/poll()/etc, the code doesn't update the timeout
in 90% of cases).
It gets a little better since the Exception hierarchy rework
(InterruptedException), but's still a nuisance.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
