Today I published fastcommand to PyPI.

fastcommand is a tiny Python package that wraps argparse, making it a little easier to create Python command-line utilities with multiple sub-commands. It provides a simple command decorator that can be used to annotate top-level functions. For example,

import fastcommand

@fastcommand.command("hello", help="say hello")
def command_hello(options):
    print("Hello, World!")

def main():
    cli = fastcommand.CommandParser(description="Simple fastcommand example.")
    cli.run()

Per-command options and arguments can be specified as follows:

@fastcommand.command("goodbye", help="say goodbye", arguments=[
    fastcommand.Argument("name"),
    fastcommand.Argument("--wave", "-w",
                         action="store_true", default=False)
])
def command_goodbye(options):
    print(f"Goodbye, {options.name}!")
    if options.wave:
        print("👋")

These sub-commands behave exactly as you’d expect:

$ examples/hello.py -h       
usage: hello.py [-h] [--verbose] {hello,goodbye} ...

Simple fastcommand example.

positional arguments:
  {hello,goodbye}  command
    hello          say hello
    goodbye        say goodbye

options:
  -h, --help       show this help message and exit
  --verbose, -v    show verbose output

$ examples/hello.py goodbye --help
usage: hello.py goodbye [-h] [--wave] name

positional arguments:
  name

options:
  -h, --help  show this help message and exit
  --wave, -ww

$ examples/hello.py goodbye Jason --wave
Goodbye, Jason!
👋

There are undoubtedly a myriad similar packages out there and, first-and-foremost fastcommand is a utility that helps me build the tools I’ve needed to develop over the years, but perhaps it can help you too. Please let me know if you use it and feel free to raise GitHub issues and pull-requests.

Publishing fastcommand is the first step in publishing some of the other Python utilities I’ve created over the years to help me with my software development—tools like changes which represents my own take on semantic versioning and conventional commits.

Continuing my journey of tailoring GNOME to better suit my needs, I present another extension that has made my experience just that little bit more seamless.

Perhaps one of the most jarring aspects of the GNOME shell is its reluctance to bring existing windows to the foreground when launched from other processes. For example, when opening a web link, GNOME presents a notification telling you Web is ‘ready’ rather than bringing an existing Web window to the foregound; focusing Web requires you to click the notification. While I trust there are good intentions behind this decision, it leaves everything feeling clunky. Thankfully, ‘Steal my focus window’ exists to bypass these interstitial notifications—a must for any GNOME setup.

Living in the terminal as much as I do, one thing that’s frustrated me with GNOME Console is it’s insistance on remembering the last window size. While this behavior might be desirable for most apps, I find I treat terminals differently—I expect them to start at a standard size that’s good enough for most actions and only expand them if the task requires it.

Thankfully, it turns out Console does support disabling window size restoration through a hidden setting:

gsettings set org.gnome.Console restore-window-size false

With this, windows will open at 80x24 by default, making everything just a little calmer and more predictable.