This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.55351e-14
Marked as misclassified No
Message-id <1296763603.3925.9.camel@localhost.localdomain>
In-reply-to <>
> > 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}.
Date User Action Args
2011-02-03 20:06:46pitrousetrecipients: + pitrou, loewis, doko, exarkun, amaury.forgeotdarc, belopolsky, benjamin.peterson, stutzbach, naufraghi, petere
2011-02-03 20:06:46pitroulinkissue7111 messages
2011-02-03 20:06:46pitroucreate