Current thinking on required options

Avi Gross avigross at verizon.net
Mon Apr 19 19:56:39 EDT 2021


Sidestepping the wording of "options" is the very real fact that providing
names for even required parts can be helpful in many cases.

There re programs that may not require anything on the command line to be
done but many need something to provide some flexibility.

So, I tend to agree that in many cases you need an explicit or implicit
argument for a program to do something useful. If I have a simple program
that looks up a phone number when given a name, it would require a name
UNLESS the default behavior is to show ALL entries or repeat whatever I
asked for last time by keeping track or provide the number I ask for most or
pick a random one or return silently having done nothing ...

But I want to point out something OBVIOUS. The requested program in my view
HAS NO required arguments! All are in a sense optional but at the same time
are all mandatory in some circumstances.

It can be called two equally valid ways:

	grocli [-h]

OR

	grocli -o {check,add,delete} -u USERS [USERS ...]] -g GROUP

When called to ask for help, none of the other arguments are required or are
ignored or worse. When called with the second properly formed set of
arguments, in any order, I assume any "-h" is either ignored or an error.

So I would possibly have TWO usage statements and in both cases, NO optional
arguments! Either you ask for help or you provide everything else.

Clearly your actual code can be designed many ways including allowing all
combinations and throwing in help when asked for in addition to doing what
is requested or allowing multiple -u arguments instead of multiple arguments
following a single -u and so forth. Heck, it can perhaps accept random
additional arguments and pass them along to another command it uses
internally without question in a "..." situation. 

So a syntax for defining a program as documentation like the above may need
an OR approach or be even more complex when say two or more arguments can be
used but only ONE is allowed and then it may be mandatory. Picture a -m to
suggest units are metric versus ...

And this "-h" notation is very common in programs and can cause the
description of how a program should be used more complex than it needs to be
if you insist on just one line showing how to use it rather than giving
several valid usages.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Dan Stromberg
Sent: Monday, April 19, 2021 12:04 PM
To: Loris Bennett <loris.bennett at fu-berlin.de>
Cc: Python List <python-list at python.org>
Subject: Re: Current thinking on required options

On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett <loris.bennett at fu-berlin.de>
wrote:

> However, the options -o, -u, and -g are required, not optional.
>
> The documentation
>
>   https://docs.python.org/3/library/argparse.html#required
>
> advises against required options and here
>
>
> https://stackoverflow.com/questions/24180527/argparse-required-argumen
> ts-listed-under-optional-arguments
>
> a way of adding a section 'required arguments' to the usage is 
> described.
>

Of _course_ some options need to be required.

I can't imagine what the author of that page was thinking.
--
https://mail.python.org/mailman/listinfo/python-list



More information about the Python-list mailing list