Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74073 > unrolled thread

open() and EOFError

Back to article view | Back to comp.lang.python

Contents

  open() and EOFError Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 03:20 +0000
    Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-07 17:04 +1200
      Re: open() and EOFError Steven D'Aprano <steve@pearwood.info> - 2014-07-07 08:00 +0000
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 18:09 +1000
        Re: open() and EOFError Dave Angel <davea@davea.name> - 2014-07-07 08:14 -0400
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 22:19 +1000
          Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 08:46 -0400
            Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 22:58 +1000
              Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 20:26 -0400
            Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-08 09:50 +1200
          Re: open() and EOFError Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 15:45 +0000
            Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 01:53 +1000
            Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 19:08 +0300
              Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 19:12 +0300
        Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 08:39 -0400
          Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 22:55 +1000
            Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 20:28 -0400
          Re: open() and EOFError Terry Reedy <tjreedy@udel.edu> - 2014-07-07 14:49 -0400
            Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-08 10:04 +1200
              Re: open() and EOFError Grant Edwards <invalid@invalid.invalid> - 2014-07-08 14:19 +0000
                Re: open() and EOFError Terry Reedy <tjreedy@udel.edu> - 2014-07-08 11:08 -0400
                Re: open() and EOFError Tim Chase <python.list@tim.thechases.com> - 2014-07-08 10:20 -0500
                Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-09 01:24 +1000
                Re: open() and EOFError Tim Chase <python.list@tim.thechases.com> - 2014-07-08 10:46 -0500
                  Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-08 21:05 -0400
                    Re: open() and EOFError Anssi Saari <as@sci.fi> - 2014-07-10 22:40 +0300
                Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-09 01:49 +1000
                Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError) Tim Chase <python.list@tim.thechases.com> - 2014-07-08 10:57 -0500
                  Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError) Jan van den Broek <balglaas@xs4all.nl> - 2014-07-08 16:38 +0000
                Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError) Chris Angelico <rosuav@gmail.com> - 2014-07-09 02:20 +1000
                Re: open() and EOFError Tim Chase <python.list@tim.thechases.com> - 2014-07-08 11:40 -0500
                Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-09 02:50 +1000
            Re: open() and EOFError Steven D'Aprano <steve@pearwood.info> - 2014-07-08 09:03 +0000
              Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 20:29 +1000
        Re: open() and EOFError Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-07 14:06 +0100
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 23:27 +1000
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 23:29 +1000
        Re: open() and EOFError Dan Stromberg <drsalists@gmail.com> - 2014-07-07 09:07 -0700
        Re: open() and EOFError Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-07 11:25 -0600
          Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 20:31 +0300
            Re: open() and EOFError Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 18:07 +0000
              Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 21:42 +0300
              Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 20:22 -0400
            Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-08 10:09 +1200
              Re: open() and EOFError Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-08 00:10 +0100
              Re: open() and EOFError "Neil D. Cerutti" <neilc@norwich.edu> - 2014-07-08 10:29 -0400
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 03:29 +1000
          Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 20:40 +0300
            Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 10:55 +1000
        Re: open() and EOFError Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-07-07 18:54 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#74131

On Mon, 07 Jul 2014 20:31:53 +0300, Marko Rauhamaa wrote:

> If the open() call is guarded against exceptions (as it usually should),
> one must revert to the classic syntax:
> 
>     try:
>          f = open(path)
>     except IOError:
>          ...
>     try:
>          ...
>     finally:
>          f.close()


try:
    f = open(path)
except Whatever:
    handle_error()
else:
    with f:
        do_stuff()



While I agree with the general idea that try blocks should be as narrow 
*as reasonable*, they shouldn't be as narrow *as possible* since one can 
start guarding against unreasonable things.

try:
    open
except NameError:
    ...
else:
    try:
        f = open(filename)
    except ZeroDivisionError:
        # Just in case open has been monkey-patched.
        ...
    except NameError:
        # Oops! Forgot to bind a value to filename!
        # Or maybe another thread deleted open??? Woe, woe!!!
        ...


The thing is, even if you catch these bizarre things, what are you going 
to do with them? If you can't do anything about it, there's no point 
catching the exception -- never catch anything you can't recover from, or 
otherwise handle. Just treat it as a fatal error and let it cause a 
traceback.

As a general rule of thumb, if you have two things which (under 
reasonable circumstances) might fail in *different* ways, then it's okay 
to put them in the same try block, and then catch the two exceptions 
separately:

try:
    do_this(with_that())
except ThatError:
    ...
except ThisError:
    ...


If you handle the exceptions the same way, then you can still put them in 
the same try block:

try:
    do_this(with_that())
except (ThatError, ThisError):
    ...


The worst case is when they might fail with the same exception, but you 
need to handle the failures differently:

try:
    a = with_that()
except ThatError:
    ...
else:
    try:
        do_this(a)
    except ThatError:
        ...


That gets old really quickly! But then, handling errors is always the 
ugliest part of coding. Hiding the messy details inside a function is 
often a good idea.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#74132

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> try:
>     f = open(path)
> except Whatever:
>     handle_error()
> else:
>     with f:
>         do_stuff()

That's cool. Never really used try-else.

> That gets old really quickly! But then, handling errors is always the
> ugliest part of coding. Hiding the messy details inside a function is
> often a good idea.

There's no way around it; life is messy.


Marko

[toc] | [prev] | [next] | [standalone]

#74142

In article <53bae1db$0$29995$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:


> While I agree with the general idea that try blocks should be as narrow 
> *as reasonable*, they shouldn't be as narrow *as possible* since one can 
> start guarding against unreasonable things.

I'm more willing to accept multi-statement try blocks with multiple 
except clauses when the things you're catching are very specific:

try:
    foo.quack()
    bar.roar()
except Foo.QuackError:
    print "OMG, can't quack"
except Bar.RoarError:
    print "Yowza"

If you're catching generic things like IOError or ValueError, it's more 
likely for there to be some code path you didn't expect.

> The thing is, even if you catch these bizarre things, what are you going 
> to do with them? If you can't do anything about it, there's no point 
> catching the exception -- never catch anything you can't recover from, or 
> otherwise handle. Just treat it as a fatal error and let it cause a 
> traceback.

That I agree with.  Of course, sometimes you do want to catch 
*everything*.  For example, in something like a web server, you want to 
have something like

try:
   do_request()
except Exception:
   handle_exception()
except:
   # WTF?  This should never happen, but deal with it anyway
   handle_exception()

way up at the top.  Our handle_exception() logs a stack trace and 
returns a 500-something HTTP response.  The alternative is to have the 
web server exit, which would be a Bad Thing.  Well, actually, if that 
happened, the gunicorn master process would catch that a worker exited 
and restart it, but that would be slow.  And if gunicorn exited, then 
upstart would catch that, and restart gunicorn :-)

[toc] | [prev] | [next] | [standalone]

#74139

Marko Rauhamaa wrote:
>     with open(path) as f:
>         ...
> 
> If the open() call is guarded against exceptions (as it usually should),
> one must revert to the classic syntax:

Hmmm, maybe we could do with a with-except statement:

    with open(path) as f:
       ...
    except IOError:
       # Catches exceptions in the with-expression only
       ...

Although that would be a bit confusing.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#74141

On 07/07/2014 23:09, Gregory Ewing wrote:
> Marko Rauhamaa wrote:
>>     with open(path) as f:
>>         ...
>>
>> If the open() call is guarded against exceptions (as it usually should),
>> one must revert to the classic syntax:
>
> Hmmm, maybe we could do with a with-except statement:
>
>     with open(path) as f:
>        ...
>     except IOError:
>        # Catches exceptions in the with-expression only
>        ...
>
> Although that would be a bit confusing.
>

I wrap the with inside a try/except, the other file handling parts 
within another try/except and use the finer grained exceptions from PEP 
3151 to write (at least to my eye) cleaner looking code.  Somehow I 
think we'll get agreement on the best way to do this when the cows come 
home.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#74167

On 7/7/2014 7:10 PM, Mark Lawrence wrote:
> On 07/07/2014 23:09, Gregory Ewing wrote:
>> Marko Rauhamaa wrote:
>>>     with open(path) as f:
>>>         ...
>>>
>>> If the open() call is guarded against exceptions (as it usually should),
>>> one must revert to the classic syntax:
>>
>> Hmmm, maybe we could do with a with-except statement:
>>
>>     with open(path) as f:
>>        ...
>>     except IOError:
>>        # Catches exceptions in the with-expression only
>>        ...
>>
>> Although that would be a bit confusing.
>
> I wrap the with inside a try/except, the other file handling parts
> within another try/except and use the finer grained exceptions from PEP
> 3151 to write (at least to my eye) cleaner looking code.  Somehow I
> think we'll get agreement on the best way to do this when the cows come
> home.

On Windows it's my experience that EOF from interactive sessions is 
ignored. Programs keep going as best they can, providing some other 
means of exit, e.g., an 'exit' command.

But maybe that's just the shell.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#74128

On Tue, Jul 8, 2014 at 3:25 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Jul 7, 2014 at 2:09 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> But if the code's more complicated and it's not so easy to split, then
>> sure, doesn't seem a problem. It's like spam[foo//bar] and then
>> catching either IndexError or ZeroDivisionError - there's no big
>> confusion from having two distinct sources of two distinct errors
>> handled by two distinct except blocks.
>
> It's good practice to keep your try blocks as narrow as possible in
> any case.  One wouldn't normally expect them, but a custom __getitem__
> *could* cause a ZeroDivisionError, and a custom __floordiv__ *could*
> cause an IndexError.

Yeah, in theory. But it's not normal, and if you always break
everything out to keep exception-catching scope as narrow as possible,
you begin to lose readability in other ways. So I wouldn't object to
seeing those two combined.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74130

Chris Angelico <rosuav@gmail.com>:

> if you always break everything out to keep exception-catching scope as
> narrow as possible, you begin to lose readability in other ways.

I've begun to wonder if there might exist a new, easier-to-read
try-except syntax.


Marko

[toc] | [prev] | [next] | [standalone]

#74145

On Tue, Jul 8, 2014 at 3:40 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> if you always break everything out to keep exception-catching scope as
>> narrow as possible, you begin to lose readability in other ways.
>
> I've begun to wonder if there might exist a new, easier-to-read
> try-except syntax.

http://www.python.org/dev/peps/pep-0463/ anyone? :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#74140

On 07 Jul 2014 08:00:14 GMT, Steven D'Aprano <steve@pearwood.info>
declaimed the following:

>How do people feel about code like this?
>
>try:
>    name = input("Enter file name, or Ctrl-D to exit")

	Personally -- I usually use "... <return> to exit" with the implication
that a null entry means exit...

	if name == "" then sys.exit()

	Of course, if I'm prompting in the first place, I'm not expecting to be
reading a (redirected?) file for data, or I'd expect the file to follow the
expected (by me)  blank line convention. Prompting for an EOF is so system
dependent... (It's been 35 years, but I think Xerox CP/V used <ctrl-f> for
EOF; it also allowed the <BEL> character in file names, making for
intriguing entry of filenames on the command line [the BASIC interpreter
DIR command would detect the non-visible character and display the entire
file name in hex... EBCDIC hex])


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web