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 belopolsky
Recipients amaury.forgeotdarc, belopolsky, benjamin.peterson, doko, naufraghi, petere, pitrou, stutzbach
Date 2011-02-03.19:56:36
SpamBayes Score 2.625374e-09
Marked as misclassified No
Message-id <AANLkTi=usftfBpySWubqmw=6Oxa=eXcAN3kzhVH9zda-@mail.gmail.com>
In-reply-to <1296762284.3925.4.camel@localhost.localdomain>
Content
On Thu, Feb 3, 2011 at 2:44 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..
>> Do you know of places where we use fd 2 instead of sys.stderr?
>
> 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?  Also, can we be sure that Python does not call C
library functions that write to stderr behind the scenes?  If vanilla
Python is safe to run with closed fd 2, that may not be the case for
3rd party extensions.    What is the use case for "python >&-"?    Is
it important enough to justify the risk of accidental data loss?
History
Date User Action Args
2011-02-03 19:56:37belopolskysetrecipients: + belopolsky, doko, amaury.forgeotdarc, pitrou, benjamin.peterson, stutzbach, naufraghi, petere
2011-02-03 19:56:37belopolskylinkissue7111 messages
2011-02-03 19:56:36belopolskycreate