> Interestingly, did you know that even *closing* a file can fail?
No I didn't, interesting piece on information for sure! I thought close() is
usually made to always succeed regardless if it actually hosed up. Any
idea what the context manager will do in that case? (I ask as that
else-with form l
> If that's what you're expecting, then your message is wrong, because
> you say "file never opened" - but you possibly DID open it, and maybe
> read something from it. The choice between the two forms should be
> based on whether you want to distinguish between errors on opening and
> errors on re
On Tue, Jul 8, 2014 at 7:00 PM, Steven D'Aprano wrote:
> Interestingly, did you know that even *closing* a file can fail?
I know that can happen with SSL sockets (which can require writing and
reading). Can't think of any situations on normal file systems where
that's true, unless the actual fail
On Tue, 08 Jul 2014 01:49:58 +0200, Alex Burke wrote:
> Hi there,
>
> While reading up on a previous thread 'open() and EOFError' I saw the
> following (with minor changes to help make my question clearer) block
> suggested as a canonical way to open files and do something:
Emphasis on "a" canon
Alex Burke :
> While reading up on a previous thread 'open() and EOFError' I saw the
> following (with minor changes to help make my question clearer) block
> suggested as a canonical way to open files and do something:
>
> try:
> f = open(path)
> except IOError:
> handle_error()
> else:
>
On Tue, Jul 8, 2014 at 9:49 AM, Alex Burke wrote:
> The reason I preferred the second was in addition to catching the
> IOError when attempting the open() if the file does not exist I
> thought I was accounting for the possibility en error occurs while
> reading data out of the file.
If that's wh
