Flags & Options: -help Me Help You

Part 2: Flags, Options, and Defaults (argparse That Doesn’t Break)

Welcome to Part 2 of the argparse mastery series — written from actual CLI-building experience, not tutorial hell.

In this part, we’re locking down the core mechanics that turn a script into a real command-line interface:

• Boolean flags
• Typed options
• Default values
• Help text that doesn’t lie

If Part 1 was about parsing arguments, this part is about designing a CLI API.

What You’ll Learn

• Boolean flags like --debug and --verbose
• Default values that prevent runtime failure
• Automatic type conversion (int, float, str)
• Writing --help output that users can trust
• Making your CLI predictable, explicit, and safe

Why This Actually Matters

A CLI without flags is just a script with aspirations.

Flags and options let users:

• Control behavior without editing code
• Experiment safely
• Automate workflows
• Debug without guesswork

Examples:

• More output → --verbose
• Internal state → --debug
• Behavior tuning → --rate, --level

This is where your script stops being fragile.

Boolean Flags (a.k.a. Feature Toggles)

A flag is an optional switch that does not take a value.

Examples:

• --verbose → enable extra output
• --debug → expose internal state
• --dry-run → simulate without executing

In argparse, this is done with:

action="store_true"

What store_true Actually Does

• The argument defaults to False
• If the flag appears on the command line → value becomes True
• No value is parsed, no ambiguity

This design prevents nonsense like:

--debug maybe

If a flag exists, it’s on. Period.

Options That Require Values

Options accept user-supplied data:

• --level 3
• --rate 0.5

These are defined with:

• type= → enforce input format
• default= → guarantee a usable value

Example:

parser.add_argument(

    "--level",

    type=int,

    default=1,

    help="Difficulty level (default: 1)"

)

If the user passes invalid input, argparse exits immediately with an error.

That’s not harsh — that’s correct.

Full Example (Flags + Typed Options)

import argparse
parser = argparse.ArgumentParser(
    description="Demo: Flags and Options in argparse"
)
# Boolean flags
parser.add_argument(
    "--debug",
    action="store_true",
    help="Enable debug mode"
)
parser.add_argument(
    "--verbose",
    action="store_true",
    help="Enable verbose output"
)
# Options with values
parser.add_argument(
    "--level",
    type=int,
    default=1,
    help="Set difficulty level (default: 1)"
)
parser.add_argument(
    "--rate",
    type=float,
    default=0.5,
    help="Set processing rate (default: 0.5)"
)
args = parser.parse_args()
if args.debug:
    print("[DEBUG] Debug mode enabled")
if args.verbose:
    print("[VERBOSE] Verbose output enabled")
print("Level:", args.level)
print("Rate:", args.rate)

Example Runs

$ python tool.py --verbose --level 3 --rate 1.2

[VERBOSE] Verbose output enabled

Level: 3

Rate: 1.2

$ python tool.py

Level: 1

Rate: 0.5

$ python tool.py --debug

[DEBUG] Debug mode enabled

Level: 1

Rate: 0.5

What argparse Is Doing for You (Quietly)

• Rejects invalid input types
• Applies defaults consistently
• Auto-documents your CLI
• Prevents undefined state

You didn’t write validation logic — argparse did.

--help Is a Contract, Not Decoration

$ python tool.py --help

Produces:

usage: tool.py [options]

Demo: Flags and Options in argparse

optional arguments:

  --debug         Enable debug mode

  --verbose       Enable verbose output

  --level LEVEL   Set difficulty level (default: 1)

  --rate RATE    Set processing rate (default: 0.5)

If this output is unclear, your CLI is broken — even if the code works.

Pro Rules (Not Suggestions)

• Use store_true for flags that default to OFF
• Always specify type= for non-string input
• Always provide default= unless failure is intentional
• Treat help= text as public API documentation
• Let argparse fail fast — don’t catch its errors prematurely

Real-World Usage

This pattern is foundational for:

• Batch file processing
• Automation scripts
• Data transformation pipelines
• DevOps tooling

Every serious CLI starts here.

Next: Part 3 — Validation & Errors

We’ll cover:

• Custom validation
• Value constraints
• Defensive CLI design
• When argparse should exit vs when you shouldn’t

Because bad input should stop execution — cleanly.

Note
If you find any part of this post unclear or technically inaccurate, I would appreciate hearing from you. Improving the precision of these explanations is an ongoing process, and your feedback helps strengthen the material.