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 1 of 3  [1] 2 3  Next page →

#74073 — open() and EOFError

Are there any circumstances where merely *opening* a file (before reading 
it) can raise EOFError?


-- 
Steven

[toc] | [next] | [standalone]

#74074

Steven D'Aprano wrote:
> Are there any circumstances where merely *opening* a file (before reading 
> it) can raise EOFError?

I don't think so. As far as I know, the only built-in
thing that raises EOFError is input() (and raw_input()
in Py2).

-- 
Greg

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

#74082

On Mon, 07 Jul 2014 17:04:12 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Are there any circumstances where merely *opening* a file (before
>> reading it) can raise EOFError?
> 
> I don't think so. As far as I know, the only built-in thing that raises
> EOFError is input() (and raw_input() in Py2).

Thanks. That's what I thought.

How do people feel about code like this?

try:
    name = input("Enter file name, or Ctrl-D to exit")
    # On Windows, use Ctrl-Z [enter] instead.
    fp = open(name)
except EOFError:
    sys.exit()
except IOError:
    handle_bad_file(name)
else:
    handle_good_file(fp)



-- 
Steven

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

#74084

On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> How do people feel about code like this?
>
> try:
>     name = input("Enter file name, or Ctrl-D to exit")
>     # On Windows, use Ctrl-Z [enter] instead.
>     fp = open(name)
> except EOFError:
>     sys.exit()
> except IOError:
>     handle_bad_file(name)
> else:
>     handle_good_file(fp)

It seems trivial in this example to break it into two try blocks:

try:
    name = input("Enter file name, or Ctrl-D to exit")
    # On Windows, use Ctrl-Z [enter] instead.
except EOFError:
    sys.exit()
try:
    fp = open(name)
except IOError:
    handle_bad_file(name)
else:
    handle_good_file(fp)

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.

ChrisA

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

#74098

Steven D'Aprano <steve@pearwood.info> Wrote in message:
> On Mon, 07 Jul 2014 17:04:12 +1200, Gregory Ewing wrote:
> 
>> Steven D'Aprano wrote:
>>> Are there any circumstances where merely *opening* a file (before
>>> reading it) can raise EOFError?
>> 
>> I don't think so. As far as I know, the only built-in thing that raises
>> EOFError is input() (and raw_input() in Py2).
> 
> Thanks. That's what I thought.
> 
> How do people feel about code like this?
> 
> try:
>     name = input("Enter file name, or Ctrl-D to exit")
>     # On Windows, use Ctrl-Z [enter] instead.
>     fp = open(name)
> except EOFError:
>     sys.exit()
> except IOError:
>     handle_bad_file(name)
> else:
>     handle_good_file(fp)
> 

Depends on who is going to be maintaining your code next year.Be
 sure and leave him some comments. Even if it's going to be you.
 

For example,  it's not obvious at a glance that name is visible in
 the second exception block and not the first. 


-- 
DaveA

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

#74099

On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> How do people feel about code like this?
>
> try:
>     name = input("Enter file name, or Ctrl-D to exit")
>     # On Windows, use Ctrl-Z [enter] instead.
>     fp = open(name)
> except EOFError:
>     sys.exit()
> except IOError:
>     handle_bad_file(name)
> else:
>     handle_good_file(fp)

Just thought of something. It's possible for input() to raise IOError,
if I'm not mistaken; consider redirection, for instance. In that case,
you would definitely want to split the try blocks, so you don't try to
"handle_bad_file" when no name was entered. (As Dave says, name hasn't
been assigned at that point, although I'd be less concerned about a
possible cascaded NameError than about a possible handle_bad_file()
with the previous name, if this is in a loop.)

ChrisA

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

#74101

In article <mailman.11587.1404735570.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> > How do people feel about code like this?
> >
> > try:
> >     name = input("Enter file name, or Ctrl-D to exit")
> >     # On Windows, use Ctrl-Z [enter] instead.
> >     fp = open(name)
> > except EOFError:
> >     sys.exit()
> > except IOError:
> >     handle_bad_file(name)
> > else:
> >     handle_good_file(fp)
> 
> Just thought of something. It's possible for input() to raise IOError,
> if I'm not mistaken; consider redirection, for instance. In that case,
> you would definitely want to split the try blocks, so you don't try to
> "handle_bad_file" when no name was entered. (As Dave says, name hasn't
> been assigned at that point, although I'd be less concerned about a
> possible cascaded NameError than about a possible handle_bad_file()
> with the previous name, if this is in a loop.)
> 
> ChrisA

My latest and greatest IOError horror story....

A guy here at work was running a Python job that was taking many days to 
complete.  He was running it on one of our production machines where we 
continually push out new releases, and clean up old ones after a few 
days.  Well, his job took longer than a few days and the directory 
containing the virtualenv he was running out of was deleted.  This 
didn't bother anything until several days later, when something deep 
inside some library function needed to open a (now missing) data file.  
Which of course, generated an IOError, which was caught in some 
unexpected place, causing all sorts of confusion trying to figure out 
WTF happened.

We've since modified our cleanup script to run lsof and skip purging any 
releases which are still in use :-)

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

#74103

On Mon, Jul 7, 2014 at 10:46 PM, Roy Smith <roy@panix.com> wrote:
> We've since modified our cleanup script to run lsof and skip purging any
> releases which are still in use :-)

LOL!

I have a computer on which I periodically build and install new
versions of a few pieces of software. Most of them don't keep running
indefinitely, but I once checked lsof and found that I had about a
dozen different versions of /usr/local/bin/pike, all executing happily
from memory. If one of them happened to go looking for some file (eg
an importable module), it'd end up picking up the latest version...
hopefully that's never a problem (chances are the different versions
aren't all *that* different - it'll just be that I pulled upstream's
edits and rebuilt).

I love how Unix will happily let you unlink a file and keep using it.
Sure, it's a pitfall for people who are trying to figure out where on
earth their disk space has gone ("I deleted that huge file, but my
disk's still full!!"), but it's soooooo much easier to work with than
"File in use, cannot delete".

ChrisA

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

#74143

In article <mailman.11589.1404737902.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> I love how Unix will happily let you unlink a file and keep using it.
> Sure, it's a pitfall for people who are trying to figure out where on
> earth their disk space has gone ("I deleted that huge file, but my
> disk's still full!!"), but it's soooooo much easier to work with than
> "File in use, cannot delete".

It's a common way to deal with temp file cleanup.

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

#74137

Roy Smith wrote:
> We've since modified our cleanup script to run lsof and skip purging any 
> releases which are still in use :-)

Or, if you're on Unix, make sure you open all the files
you're likely to need at the beginning and hold onto
them. :-)

-- 
Greg

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

#74117

On Mon, 07 Jul 2014 22:19:20 +1000, Chris Angelico wrote:

> It's possible for input() to raise IOError, if I'm not mistaken;
> consider redirection, for instance.

What indirection? Do you mean, if built-in input() has been monkey-
patched? Well, sure, but in that case it could do anything. I'm only 
concerned with the builtins. Otherwise, I have no idea what you mean by 
that.

https://docs.python.org/3/library/functions.html#input



-- 
Steven

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

#74119

On Tue, Jul 8, 2014 at 1:45 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 07 Jul 2014 22:19:20 +1000, Chris Angelico wrote:
>
>> It's possible for input() to raise IOError, if I'm not mistaken;
>> consider redirection, for instance.
>
> What indirection? Do you mean, if built-in input() has been monkey-
> patched? Well, sure, but in that case it could do anything. I'm only
> concerned with the builtins. Otherwise, I have no idea what you mean by
> that.
>
> https://docs.python.org/3/library/functions.html#input

I said redirection, not indirection, and I was thinking of OS-level
changes. If input() is actually reading from some file/device, then
any error that that could raise could come up from reading from stdin.
Imagine if your script is running with input redirected from a file on
a dodgy remote mount, and the far end goes down - at some point,
you'll attempt to read and fail. I'm not sure that you'll see EOF
then; by rights, you ought to see some other error.

ChrisA

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

#74121

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

> On Mon, 07 Jul 2014 22:19:20 +1000, Chris Angelico wrote:
>
>> It's possible for input() to raise IOError, if I'm not mistaken;
>> consider redirection, for instance.
>
> What indirection? Do you mean, if built-in input() has been monkey-
> patched? Well, sure, but in that case it could do anything. I'm only
> concerned with the builtins. Otherwise, I have no idea what you mean
> by that.

input() quite naturally can raise an IOError. For example:

    import os, socket
    s = socket.socket(socket.AF_UNIX)
    s.bind("xyz")
    os.dup2(s.fileno(), 0); print(input())

results in an IOError (EINVAL, to be exact).

strace reveals that input() simply delegates to:

  read(0, 0xb73aa000, 4096)               = -1 EINVAL (Invalid argument)


Marko

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

#74122

Marko Rauhamaa <marko@pacujo.net>:

> input() quite naturally can raise an IOError. For example:
>
>     import os, socket
>     s = socket.socket(socket.AF_UNIX)
>     s.bind("xyz")
>     os.dup2(s.fileno(), 0); print(input())
>
> results in an IOError (EINVAL, to be exact).

Even simpler:

   >>> import os
   >>> os.close(0); input()
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   IOError: [Errno 9] Bad file descriptor


Marko

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

#74100

In article <53ba538d$0$2926$c3e8da3$76491128@news.astraweb.com>,
 Steven D'Aprano <steve@pearwood.info> wrote:

> On Mon, 07 Jul 2014 17:04:12 +1200, Gregory Ewing wrote:
> 
> > Steven D'Aprano wrote:
> >> Are there any circumstances where merely *opening* a file (before
> >> reading it) can raise EOFError?
> > 
> > I don't think so. As far as I know, the only built-in thing that raises
> > EOFError is input() (and raw_input() in Py2).
> 
> Thanks. That's what I thought.
> 
> How do people feel about code like this?
> 
> try:
>     name = input("Enter file name, or Ctrl-D to exit")
>     # On Windows, use Ctrl-Z [enter] instead.
>     fp = open(name)
> except EOFError:
>     sys.exit()
> except IOError:
>     handle_bad_file(name)
> else:
>     handle_good_file(fp)

I really dislike putting more than one statement inside a try block.  
Breaking this up into two try statements, one catching the EOF, the 
other catching the IOError, is better.  More verbose, to be sure, but 
the flow of control is a lot more obvious.

On a different topic, I've always disliked embedding instructions to 
"type Ctrl-D".  The problem is, how to generate an EOF (or interrupt, or 
whatever) is configurable in the tty driver (see below).  In theory, the 
user could have remapped EOF to be something else.  Maybe they're a 
die-hard Windows fan, and insist on being able to type Ctrl-Z for EOF.  
Not to mention that things like readline are probably running the 
terminal in raw mode and remapping everything all over again.

On the other hand, telling the user to "generate EOF", while technically 
more correct, is not very useful for most people.  I suppose you could 
interrogate the tty driver to find out what the current EOF character 
is, and stick that in your prompt.  I don't even know if that's possible 
with the standard Python library, and I doubt it would be very portable.    
I'm not sure what the best solution is here.

------------------------------------------------------
$ stty -e
speed 9600 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
   -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
   -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
   -ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
   -dtrflow -mdmbuf
discard dsusp   eof     eol     eol2    erase   intr    kill    lnext   
^O      ^Y      ^D      <undef> <undef> ^?      ^C      ^U      ^V      
min     quit    reprint start   status  stop    susp    time    werase  
1       ^\      ^R      ^Q      ^T      ^S      ^Z      0       ^W      
------------------------------------------------------

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

#74102

On Mon, Jul 7, 2014 at 10:39 PM, Roy Smith <roy@panix.com> wrote:
> $ stty -e
> speed 9600 baud; 24 rows; 80 columns;
> lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
>    -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
>    -extproc
> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
>    -ignbrk brkint -inpck -ignpar -parmrk
> oflags: opost onlcr -oxtabs -onocr -onlret
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
>    -dtrflow -mdmbuf
> discard dsusp   eof     eol     eol2    erase   intr    kill    lnext
> ^O      ^Y      ^D      <undef> <undef> ^?      ^C      ^U      ^V
> min     quit    reprint start   status  stop    susp    time    werase
> 1       ^\      ^R      ^Q      ^T      ^S      ^Z      0       ^W

Not sure what you're running, but 'stty -e' throws an error for me
(Debian Wheezy). I get fairly similar output from 'stty -a', though;
and it's marginally more parseable:

rosuav@sikorsky:~$ stty -a
rosuav@sikorsky:~$ stty -a
speed 38400 baud; rows 55; columns 190; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?;
eol2 = M-^?; swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt =
^R; werase = ^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff -iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

(That's off a maximized window. If I restore the window, I get a more
classic 24x80.)

The same info can be queried in Python via
termios.tcgetattr()[6][termios.VEOF] but you then have to parse that
to interpret it for a human (it comes out as b'\4', which you have to
figure out means ^D). I'm not sure if there's a utility function
anywhere for "give me the human readable form of this".

ChrisA

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

#74144

In article <mailman.11588.1404737728.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Mon, Jul 7, 2014 at 10:39 PM, Roy Smith <roy@panix.com> wrote:
> > $ stty -e
[...]
> Not sure what you're running, but 'stty -e' throws an error for me
> (Debian Wheezy).

That was on OSX.

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

#74133

On 7/7/2014 8:39 AM, Roy Smith wrote:

> On a different topic, I've always disliked embedding instructions to
> "type Ctrl-D".  The problem is, how to generate an EOF (or interrupt, or
> whatever) is configurable in the tty driver (see below).  In theory, the
> user could have remapped EOF to be something else.  Maybe they're a
> die-hard Windows fan, and insist on being able to type Ctrl-Z for EOF.
> Not to mention that things like readline are probably running the
> terminal in raw mode and remapping everything all over again.
>
> On the other hand, telling the user to "generate EOF", while technically
> more correct, is not very useful for most people.  I suppose you could
> interrogate the tty driver to find out what the current EOF character
> is, and stick that in your prompt.  I don't even know if that's possible
> with the standard Python library, and I doubt it would be very portable.
> I'm not sure what the best solution is here.

Avoid EOFError. Much better, I think, is the somewhat customary

s = input("Enter something, or hit <return> to exit")
if not s: sys.exit()
else: <process s>

-- 
Terry Jan Reedy

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

#74138

Terry Reedy wrote:
> Avoid EOFError. Much better, I think, is the somewhat customary
> 
> s = input("Enter something, or hit <return> to exit")
> if not s: sys.exit()
> else: <process s>

I beg to differ -- on Unix, Ctrl-D *is* the customary
way to exit from something that's reading from stdin.

In any case, you need to be able to handle EOF gracefully
if the user uses it.

-- 
Greg

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

#74166

On 2014-07-07, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:
> Terry Reedy wrote:
>> Avoid EOFError. Much better, I think, is the somewhat customary
>> 
>> s = input("Enter something, or hit <return> to exit")
>> if not s: sys.exit()
>> else: <process s>
>
> I beg to differ -- on Unix, Ctrl-D *is* the customary
> way to exit from something that's reading from stdin.

Indeed.  Ctrl-D is _the_ canonical way to tell a program that's
reading stdin that your're done.

I've never run across "hit <return> to exit".

> In any case, you need to be able to handle EOF gracefully if the user
> uses it.

-- 
Grant Edwards               grant.b.edwards        Yow! Nipples, dimples,
                                  at               knuckles, NICKLES,
                              gmail.com            wrinkles, pimples!!

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web