Python supports the use of command line arguments providing developers an easy entry point for accepting program arguments. Complex Python programs or simple scripts can be run, with arguments, directly from the terminal.<\/p>\n
Python provides support for command line usage via the Command line interfaces (CLI) have been a common means of providing input to computer programs since the advent of the computer terminal. As early as the 1950’s computers began using terminals to interface with users in real-time, such as Jay Forrester’s Whirlwind computer1<\/sup>. Modern CLI applications are often run via a Shell2<\/sup>. As described by the developer of the original Unix Shell – Ken Thompson3<\/sup>:<\/p>\n The Shell is a command line interpreter: it reads lines typed by the user and interprets them as requests to execute other programs. In simplest form, a command line consists of the command name followed by arguments to the command, all separated <\/em>by spaces<\/em><\/p>\n We’ll not dive any further into the history \u2014 but halt and focus on part of Thompson’s description: the command name followed by arguments to the command<\/em>. This is the essence of command line arguments and how, even today, a Python script accepting command line arguments is executed. Now we know the format, let’s consider how Python interprets our command and arguments.<\/p>\n Python’s command line arguments are accessible via the sys module. This format is modeled after the C-Language’s use of the parameters According to the latest ISO C-language standards, The function called at program startup is named main … \u00a0with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared)<\/em><\/p>\n C convention states the primary function is called main \u2014 another C-language feature adopted by Python. Python defines what is known as a “top-level code environment<\/a>” in which the first user-specified module starts to run\u2014i.e. the code that would accept command line arguments.<\/p>\n In keeping with C-language conventions, this Python’s The name of our program is Notice the first argument is the name of our program \u2014 meaning the total number of arguments is the length of the Python’s The first two points are relatively trivial and can be addressed via common Python syntax. The third gets a bit more complex but is relatively easy via the Error handling consists of two primary concerns: the minimum required number of arguments has been supplied and the program isn’t trying to access arguments that aren’t there \u2014 both are closely related. Consider the following command line execution of our program What if the program expects a third value Attempting to access index 3 will cause an This makes a call to SystemExit if the number of arguments is fewer than the three expected. Remember \u2014 we’re comparing to 4 because the name of the program ( Values found in Each program is likely to have custom requirements for each argument. However, a general approach is suitable for many cases by which the type of a value is checked. Let’s consider an example where every argument is expected to be an integer value:<\/p>\n This program loops over all elements in the sys<\/code>, argparse<\/code>, getopt<\/code> and other modules from the standard library. These modules make short work of parsing and checking command line arguments as well as adding options, flags, and even handling basic logical functions. Before we dive in, let’s consider where the Python command line came from.<\/p>\nThe Command Line Interface (CLI)<\/h2>\n
ArgC & ArgV<\/h2>\n
argc<\/code> and argv<\/code>. These represent the following values:<\/p>\n\n
agrc<\/code> and argv<\/code> can be further contextualized by considering a function named main<\/code>4<\/sup>:<\/p>\nmain<\/code> program (receiving the __name__ attribute of __main__ in Python) provides access to any command line arguments via the argc<\/code> and argv<\/code> methods provided in the sys module. Enough with the history and technical details \u2014 let us now look at how to handle command line arguments in Python.<\/p>\nThe sys Module, argc, & argv<\/h2>\n
sys<\/code> module<\/a> “provides access to some variables used or maintained by the interpreter.”\u00a0 This module provides a list of all command line arguments accessible as sys.argv<\/code>. There is no sys.argc<\/code> but the number of arguments can be measured by taking the length of argv – 1. Let’s see an example via running a fake program and taking 3 arguments.<\/p>\n$ python3 fake_func.py val1 val2 val3<\/code><\/p>\nfake_func.py<\/code> and val1<\/code>, val2<\/code>, and val3<\/code> are the arguments being passed as command line arguments. The value of sys.argv<\/code> in this case would be as follows:<\/p>\nargv: ['fake_func.py', 'val1', 'val2', 'val3']<\/code><\/p>\nargv<\/code> list – the name of the program. In Python: len(sys.argv) - 1<\/code>. This will return the integer value 3<\/code> serving as a stand-in for argc<\/code>.<\/p>\nParsing Command Line Arguments<\/h2>\n
sys.argv<\/code> works great at retrieving command line arguments but offers no support at handling them. For that, each program will have unique requirements. There are some common concerns that are relevant to any use of the sys.argv however:<\/p>\n\n
sys.argv<\/code> returns string values that may need to be cast to other types.<\/li>\nargparse<\/code> module. Below is a brief discussion of each point of concern.<\/p>\nError Handling<\/h3>\n
fake_prog.py<\/code> again:<\/p>\n$ python3 fake_prog.py arg1 arg2<\/code><\/p>\narg3<\/code>? Presumably, the program would have code to access that via syntax similar to the following: sys.argv[3]<\/code>. In this case, argv<\/code> would only have three values: ['fake_prog.py', 'arg1', 'arg2']<\/code> and length 3<\/code>.<\/p>\nIndexError<\/code> exception. This issue can be handled in one of two ways: an initial check<\/strong> for the correct count or individual checking<\/strong> for each argument. The first is more holistic, and can be implemented as follows:<\/p>\nimport sys\r\n\r\n# Checks for the correct number of arguments\r\nif len(sys.argv) != 4:\r\n raise SystemExit(\"Usage: python3 fake_prog.py arg1 arg2 arg3\")<\/pre>\n
fake_prog.py<\/code>) will always be the first argument. An alternative approach would use a try-except<\/code> block for an IndexError<\/code> for each access. We’ll skip that code since it’s cumbersome and stinks<\/em><\/a>.<\/p>\nType Conversions<\/h3>\n
sys.argv<\/code> are interpreted as string values \u2014 a characteristic common to most programming languages. That leaves the conversion to non-string values up to us developers. This will mostly be a case of parsing a value as a numerical type (float<\/code>, int<\/code>, etc.), a String<\/code>, or a char<\/code>.<\/p>\nimport sys\r\n\r\n# Tries to convert all arguments to an integer\r\nfor arg in sys.argv[1:]:\r\n try:\r\n parsed = int(arg)\r\n except ValueError:\r\n raise SystemExit(\"All arguments must be an integer!\")<\/pre>\n
sys.argv<\/code> list \u2014 other than the first argument which is the program name \u2014 and attempts to convert the string value to an integer. If this fails with a ValueError<\/code>, the program will exist and display a usage message. This will cause the program to exit if any argument is not an integer value<\/strong>. A similar approach can be used to handle a wide range of requirements for parsing command line args.<\/p>\nFlags & Options<\/h3>\n