[Python-3000] test_mmap.py and OSError

[Guido van Rossum]

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 test_io.py and test_file.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/)