Message127813
| Author |
pitrou |
| Recipients |
amaury.forgeotdarc, belopolsky, benjamin.peterson, doko, exarkun, loewis, naufraghi, petere, pitrou, stutzbach |
| Date |
2011年02月03日.20:06:46 |
| SpamBayes Score |
2.553513e-14 |
| Marked as misclassified |
No |
| Message-id |
<1296763603.3925.9.camel@localhost.localdomain> |
| In-reply-to |
<AANLkTi=usftfBpySWubqmw=6Oxa=eXcAN3kzhVH9zda-@mail.gmail.com> |
| Content |
> > We normally don't. One reason is that buffering inside sys.stderr can
> > make ordering of output incorrect. There are some places in C code where
> > we do "fprintf(stderr, ...)" but that's for specialized debugging
> > (disabled in normal builds) or fatal error messages.
>
> This is the case that I had in mind. What does non-debug build do on
> a fatal error?
It uses fprintf(stderr, ...). That's the only thing it can do (there's
no way sys.stderr is guaranteed to be usable at that point). If C stderr
is invalid, then too bad.
> Also, can we be sure that Python does not call C
> library functions that write to stderr behind the scenes?
I think you can guess the answer :)
> What is the use case for "python >&-"? Is
> it important enough to justify the risk of accidental data loss?
I don't think so. One more important use case is when running a Unix
daemon, which has (AFAIK) to close all std handles. I don't know how
that interacts with using C stderr, especially if the handle closing is
done in Python (and therefore only calls C close() and not fclose()!).
Perhaps we should provide a sys function to fclose() C std{in,out,err}. |
|