[Python-Dev] PEP 389: argparse - new command line parsing module (original) (raw)
Steven D'Aprano steve at pearwood.info
Sat Oct 3 20:22:28 CEST 2009
- Previous message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Next message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, 4 Oct 2009 04:46:19 am Yuvgoog Greenle wrote:
I just think that if a parser error is causing the SystemExit, I would rather catch a parser error than catching a SystemExit for the sake of readability. It saves me the comments:
# Catching SystemExit because parseargs() throws SystemExit on parser errors.
But why are you catching the error? As a general rule, you want your command line app to exit if it can't understand the arguments you pass to it. What else can it do? Guess what you wanted?
Assuming you have a reason for catching the exception, I don't see that there's any difference in readability between these:
parser = argparse.ArgumentParser() setup_args(parser) try: ns = parser.parse_args() except argparse.ParserError: process_error() else: main(ns)
and:
parser = argparse.ArgumentParser() setup_args(parser) try: ns = parser.parse_args() except SystemExit: process_error() else: main(ns)
You don't need a comment warning that you are catching SystemExit because parse_args raises SystemExit, any more than you need a comment saying that you are catching ValueError because some function raises ValueError. The fact that you are catching an exception implies that the function might raise that exception. A comment like:
"Catching SystemExit because parse_args() throws SystemExit on parser errors."
is up them with comments like this:
x += 1 # Add 1 to x.
-- Steven D'Aprano
- Previous message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Next message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]