sys.exit()

[Ivan Voras]

In a code such as:

if len(sys.argv) < 2:
print "I need arguments!"
sys.exit(1)

Is sys.exit() really a good choice? Is there something more elegant? (I
tried return but it is valid only in a function)
--
--
Every sufficiently advanced magic is indistinguishab le from technology
- Arthur C Anticlarke

[Donn Cave]

Quoth "Ivan Voras" <iv****@fer.hr> :
| In a code such as:
|
| if len(sys.argv) < 2:
| print "I need arguments!"
| sys.exit(1)
|
| Is sys.exit() really a good choice? Is there something more elegant? (I
| tried return but it is valid only in a function)

Your question has already been answered many times over, so I will
instead note something about the above that is rather common but
wrong. "print" writes to sys.stdout (unless instructed otherwise),
and in the present case this output should certainly go to sys.stderr.
The easiest way to do that in recent versions of python (2.0 and
later) is "print >> sys.stderr".

Donn Cave, do**@drizzle.co m

[Duncan Booth]

"Donn Cave" <do**@drizzle.c om> wrote in news:1065757907 .371391@yasure:

| Is sys.exit() really a good choice? Is there something more elegant? (I
| tried return but it is valid only in a function)

Your question has already been answered many times over, so I will
instead note something about the above that is rather common but
wrong. "print" writes to sys.stdout (unless instructed otherwise),
and in the present case this output should certainly go to sys.stderr.
The easiest way to do that in recent versions of python (2.0 and
later) is "print >> sys.stderr".

Note that the suggestions to use "sys.exit(messa ge)" or "raise
SystemExit(mess age)" will send the message to sys.stderr. This is probably
easier than doing it explicitly in a separate print statement, plus it has
the advantage that if you want to catch the exit for any reason you also
catch the error message.

I've actually ended up doing this on occasion in unit tests, if you are
testing something that should cause a fatal error its a lot easier if the
error message is encapsulated in the SystemExit exception.

--
Duncan Booth du****@rcp.co.u k
int month(char *p){return(1248 64/((p[0]+p[1]-p[2]&0x1f)+1)%12 )["\5\x8\3"
"\6\7\xb\1\x9\x a\2\0\4"];} // Who said my code was obscure?

[Donn Cave]

Quoth Duncan Booth <du****@NOSPAMr cp.co.uk>:
| "Donn Cave" <do**@drizzle.c om> wrote in news:1065757907 .371391@yasure:
....
|> Your question has already been answered many times over, so I will
|> instead note something about the above that is rather common but
|> wrong. "print" writes to sys.stdout (unless instructed otherwise),
|> and in the present case this output should certainly go to sys.stderr.
|> The easiest way to do that in recent versions of python (2.0 and
|> later) is "print >> sys.stderr".
|
| Note that the suggestions to use "sys.exit(messa ge)" or "raise
| SystemExit(mess age)" will send the message to sys.stderr. This is probably
| easier than doing it explicitly in a separate print statement, plus it has
| the advantage that if you want to catch the exit for any reason you also
| catch the error message.
|
| I've actually ended up doing this on occasion in unit tests, if you are
| testing something that should cause a fatal error its a lot easier if the
| error message is encapsulated in the SystemExit exception.

That's right, it does work and it is easier. But please don't think
of print >> sys.stderr as something that's hard, lest that lead to
code like distutils that just neglects to do it.

distutils perhaps has the excuse that it had this problem before there
was a solution, but it's a good example of the problem. It's natural
to want to save the output of distutils to disk - I think it's really a
good practice to do this routinely so later you know how an application
was built, what went into it and where it got installed. In this case,
you'd always redirect both stdout and stderr, with a shell command line
like 'python setup.py > make.log 2>&1', so it would seem that the choice
between stdout and stderr would not matter. But it matters a lot, because
when stdout is a disk file, it's block buffered. That means the actual
flush to disk may be deferred for some time. Meanwhile, the applications
and processes that distutils invokes (cc, etc.) write immediately to disk
because if nothing else their output buffers flush when they exit. So
your log file starts with a bunch of diagnostic output from cc, and only
later gets to the distutils output that announces it's going to run cc.
Completely unreadable. stderr is always line buffered.

Donn Cave, do**@drizzle.co m