Why is the argparse module so inflexible?

[Steven D'Aprano]

On Fri, 28 Jun 2013 18:36:37 -0700, Ethan Furman wrote:

> On 06/27/2013 03:49 PM, Steven D'Aprano wrote:
>>
>> [rant]
>> I think it is lousy design for a framework like argparse to raise a
>> custom ArgumentError in one part of the code, only to catch it
>> elsewhere and call sys.exit. At the very least, that OUGHT TO BE A
>> CONFIG OPTION, and OFF BY DEFAULT.

[emphasis added]

>> Libraries should not call sys.exit, or raise SystemExit. Whether to
>> quit or not is not the library's decision to make, that decision
>> belongs to the application layer. Yes, the application could always
>> catch SystemExit, but it shouldn't have to.
> 
> So a library that is explicitly designed to make command-line scripts
> easier and friendlier should quit with a traceback?
> 
> Really?

Yes, really.

Tracebacks are not that unfriendly, generally speaking. In my experience, 
the average non-technical person is no more confused and distressed by a 
traceback extending over thirty lines than they are by a one line error 
message. As the developer, I should see the tracebacks by default[1]. If 
I want to suppress or simplify them, then I should take explicit steps to 
do so, either by catching the exception and calling sys.exit myself, or 
at least by setting a runtime config option to the library.

This also allows me to enable debugging in my app by showing tracebacks, 
or disable it by hiding them. That should be my decision, not the 
library. If the library catches exceptions then exits, throwing away 
potentially useful information, that makes it difficult to debug anything 
relying on the library.

I'm willing to concede that, just maybe, something like argparse could 
default to "catch exceptions and exit" ON rather than OFF. 


[1] There's something in the Zen of Python about that...


-- 
Steven