I believe the governing document for how this should be specified is IEEE Standard 1003.1,
a.k.a. POSIX [1].
That standard defines two attributes for command line arguments. An argument
can be mandatory or optional, which is pretty straightforward. An argument also
can either be a keyword argument - which is denoted by starting with one or more
dashes followed by one or more alphanumeric characters - or it can be a
positional argument (also known as an operand) whose meaning is indicated by
it's position relative to the other positional arguments. Conflating the
mandatory/optional aspect and the keyword/operand aspect will definitely induce
confusion.
I understand that the cliff behavior is transparently representing the way argparse
processes options but I think we have the opportunity to check the required field in the
array of optional arguments, and create a new argument group for optional-but-required
arguments.
I believe the governing document for how this should be specified is IEEE Standard 1003.1,
a.k.a. POSIX [1].
That standard defines two attributes for command line arguments. An argument
can be mandatory or optional, which is pretty straightforward. An argument also
can either be a keyword argument - which is denoted by starting with one or more
dashes followed by one or more alphanumeric characters - or it can be a
positional argument (also known as an operand) whose meaning is indicated by
it's position relative to the other positional arguments. Conflating the
mandatory/optional aspect and the keyword/operand aspect will definitely induce
confusion.
I understand that the cliff behavior is transparently representing the way argparse but-required
processes options but I think we have the opportunity to check the required field in the
array of optional arguments, and create a new argument group for optional-
arguments.
[1] in part https:/ /pubs.opengroup .org/onlinepubs /9699919799/ basedefs/ V1_chap12. html#tag_ 12_01