Python Tutorial: argparse advanced-help with additional options - thing.py

Example script: https://gist.github.com/thingsiplay/ae9a26322cd5830e52b036ab411afd1f

Hi all. I just wanted to share a way to handle a so called advanced help menu, where additional options are listed that are otherwise hidden with regular help. Hidden options should still function. This is just to have less clutter in normal view.

I’ve researched the web to see how people does it, and this is the way I like most so far. If you think this is problematic, please share your thoughts. This is for a commandline terminal application, that could also be automated through a script.

How it works on a high level

Before the ArgumentParser() is called, we check the sys.argv for the trigger option --advanced-help. Depending on this we set a variable to true or false. Then with the setup of the parser after the ArgumenParser() call, we add the --advanced-help option to the list of regular help.

advanced_help = False
for arg in sys.argv:
    if arg == "--":
        break
    if arg == "--advanced-help":
        advanced_help = True

parser = argparse.ArgumentParser()

Continue setting up your options as usual. But for the help description of those you want to exclude when using just regular -h, add an inline if else statement (ternary statement). This statement will put the help description only if advanced_help variable is true, otherwise it puts argparse.SUPPRESS to hide the option. Do this with all the options you want to hide.

parser.add_argument(
    "-c",
    "--count",
    action="store_true",
    default=False,
    help="print only a count of matching items per list, output file unaffected"
    if advanced_help
    else argparse.SUPPRESS,
)

At last we need to actually parse what you just setup. For this we need to assign our custom list, that is based on the sys.argv, plus the regular --help option. This way we can use --advanced-help without the need for -h or --help in addition to show any help message.

if advanced_help:
    args = parser.parse_args(sys.argv[0:0] + ["--help"] + sys.argv[1:])
else:
    args = parser.parse_args()

Run following program once with ./thing.py -h and ./thing.py --advanced-help.

  • logging_strict@programming.dev
    2·
    3 days ago

    people are forced to install dependencies

    This ^^.

    If possible, Python dependency management is a burden would prefer to avoid. Until can’t, then be skilled at it!

    disclosure: i use/wrote wreck for Python dependency management.

    Compiled languages should really live within containers. At all cost, would like to avoid time consuming system updates! I can no longer install C programs cuz on OS partition ran out of hard disk space. Whereas Python packages can be installed on data storage partitions.

    for Python, I usually deliver the script as a single .py file I’m sure you are already aware of this. So forgive me if this is just being Captain Obvious.

    Even if the deliverable is a single .py file, there is support for specifying dependencies within module level comment block. (i forget the PEP #).

    I don’t like that (unless its a shell script, but that is by its nature a dependency hell) You and i could bond over a hatefest on shell scripts, but lets leave this as outside the discussion scope

    And your argument As the complexity of a .py script grows, very quickly, comes to a point the deliverable becoming a Python package. With the exceptions being projects which are: external language, low level, or simple. This .py script nonsense does not scale and is exceedingly rare to encounter. May be an indication of a old/dated or unmaintained project.

    From a random venv, installed scripts:

    _black_version.py
appdirs.py
cfgv.py
distutils-precedence.pth
mccabe.py
mypy_extensions.py
nodeenv.py
packaging_legacy_version.py
pip_requirements_parser.py
py.py
pycodestyle.py
pyi.py
six.py
typing_extensions.py
    • thingsiplay@beehaw.orgOP
      2·
      3 days ago

      BTW, I’m not saying the way I am going and doing this is the right one. In the end I use additional packages when needed, BeautifulSoup as an example to make life really easier. But that is something specific to that script. Stuff like click and argparse is more than a single script, because when I switch to click then all my future scripts would depend on it. And I feel more comfortable with a solution that is already built-in (stdlib) if its not too bad.

      I don’t see click as a required package that I really need. And that is also true for many other packages, such as requests one.

      • logging_strict@programming.dev
        1·
        3 days ago

        There is an expression, Linux isn't free it costs you your time. Which might be a counter argument against always using only what is built in.

        I’m super guilty of reinventing the wheel. But writing overly verbose code isn’t fun either. Never seem to get very far.

        • thingsiplay@beehaw.orgOP
          2·
          3 days ago

          There is an expression, Linux isn’t free it costs you your time.

          Just because someone said it does not make it true and certainly, I don’t have to live after that expression. It kind of is a catch all phrase to justify (or not to justify) everything. It could also be used as an argument for “Vibe Coding” (I hate that term…).

          I mean this argument about Linux does not apply to every single application (you apply it right now here to some random Python script). In example Windows, MacOS, Android, nothing is free and costs you your time. The question is, how you want spent your time. And I enjoy writing programs and scripts for various reasons.

          I personally think reinventing the wheel is great. Why? It makes you learn and do it. It makes you less dependent. The end result might not be the most polished one, but also if nobody reinvents the wheel, then we have no competition. Sure you should not reinvent everything, there is a balance act to make. And this balance is different for everyone else.