STINNER Victor added the comment:

> I don't know. I don't know why OSError and ValueError are caught at all.

Ha ha, me neither. Maybe it's time to remove them an wait for user feedback :-)

> What are you think about deterministic closing standard streams in 
> cleanup_std_streams.patch? There is no haste to commit this.

This change has two parts.

For the "stdout.flush() ... stdout.close() ... stdout = None" part:

* It looks like a good idea to set stout (and stderr) to None, since I see many 
C code having an explicit "stream is None" check (handle correctly this case).
* For the flush part: I would prefer to share code with pylifecycle.c, 
flush_std_files(). Maybe we can log flush error into the C stderr stream? 
(Maybe with a flag when we know that Python finalization has started, or check 
_Py_Finalizing?)
* For the close part: I don't know. I like the idea of being able to use print 
until the last Python instruction.

Instead of closing and setting stdout/stderr to None, what do you think of 
using something similar than Py_Initialize():

    /* Set up a preliminary stderr printer until we have enough
       infrastructure for the io module in place. */
    pstderr = PyFile_NewStdPrinter(fileno(stderr));
    if (pstderr == NULL)
        Py_FatalError("Py_Initialize: can't set preliminary stderr");
    _PySys_SetObjectId(&PyId_stderr, pstderr);
    PySys_SetObject("__stderr__", pstderr);
    Py_DECREF(pstderr);

This printer has limitations, but it can help to get very late messages during 
Python finalization.

If we use this printer, it reduces the pressure on the exact order of 
operations.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25654>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to