00:00 In the previous lesson, I showed you the different kinds of actions you could use to control how arguments are stored. In this lesson, I’ll be talking about controlling how many parameters there are for your arguments.
You use the
nargs parameter when creating an argument to control how many things are consumed. But just what do I mean by that? Well, if you’re using it with a positional argument, the value of
nargs is the count of the number of arguments to process and store as a list. If you’re using an optional flag,
nargs specifies how many parameters to expect after the flag.
It is also stored as a list. Do you feel lucky, punk? Remember back when I was on the waterfront, and the program crashed because I gave two few
-w arguments? This fixes that. Dirty Harry here uses the
nargs parameter to specify how many
-ws to expect.
3, in this case. I feel lucky. Do you feel lucky?
On line 6, I was explicit about using the
store action so you could see what I was doing was something different from the Waterfront example, which used
append. But remember,
store is the default, so I didn’t really need to do that.
This time I’m using a positional argument. The
* (star) value to
nargs indicates that this script takes zero or more arguments, essentially consuming all of the positional arguments. Paging down … The rest of the script prints out the countdown, and if the current line of the count is in the
tee argument list, then
T-minus gets printed before the number. Total aside, but Cape Kennedy is an amazing place. If you ever find yourself in Florida, it is well worth the visit. Just bring the extra-powerful bug spray.
Line 9 sets
nargs to the
REMAINDER constant. This says to consume whatever is left of the positional arguments. In this case, this would be no different than
*, but there are some corner cases with very complex parsing where it might be cleaner to use this instead. This script has three sentences, which it prints out interjected with the
Become a Member to join the conversation.