[Python-3000] test_mmap.py and OSError (original) (raw)

Guido van Rossum guido at python.org
Mon Jul 16 20:29:17 CEST 2007

So, after seeing the patch and thinking this over some more, I have changed my mind (again). Attempting to flush a closed file seems to indicate that you're confused about whether a file is closed or not, and that seems indicative of unclear thinking, i.e. it's likely a bug that ought to be caught. I think the original thinking that lead to this being treated as an error in 2.x was correct.

I don't see attempts to close an already closed file the same way -- this is a state transition to a final state and it makes total sense that you can reach that state from itself. There are good use cases for allowing this. I don't see the use case for flushing a closed file.

--Guido

On 7/12/07, Joe Gregorio <joe at bitworking.org> wrote:

On 7/12/07, Guido van Rossum <guido at python.org> wrote: > On 7/12/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > > Joe Gregorio wrote: > > > flush() raises > > > ValueError() if the file is already closed, > > > > > > Should io.py raise OSError instead of ValueError? > > > > Is it really necessary to raise anything at all? > > An already-closed file is as flushed as it can > > get, so why not just let it be a no-op? > > I like that much better. So close() shouldn't try to flush() if it's > already closed. This means fixing io.py. (Unfortunately it's a bit of > a mess, a bit of refactoring would do it good.)

Thanks for the guidance. This patch fixes mmap and also changes io.py so that close() doesn't flush if it's already closed. I did run both testio.py and testfile.py when checking the changes to io.py. http://www.python.org/sf/1752647 Thanks, -joe -- Joe Gregorio http://bitworking.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list