On 7/16/07, Joe Gregorio <[EMAIL PROTECTED]> wrote: > On 7/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > 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. > > Personally I like that better, it seems more consistent. > > Should I change the try/except block in the mmap unit test to look for > ValueError or should the exception raised in io.py be of type OSError like > the 2.5 code expects? > > test_mmap.py:108 > > try: > f.close() > except OSError: > pass > > Thanks, > -joe
I just checked in your changes, but looking at the code, I think it's bogus either way: there should be two separate try/finally blocks corresponding to the two 'f = open(...)' calls. I'll fix it that way. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
