While Typer looks nice, I found it to be annoying. It outputs everything depending on the width of your terminal emulator with spaces instead of newlines. Not sure who thought that was a good idea, but try copy pasting any output of it in any chat or anywhere that is not the same width in chars as your terminal emulator. The output becomes complete shit and unreadable. The second thing is, that it forces you to adhere to its paradigm of being a global mutable state object, instrad of being passed around neatly like argsparse, which makes code less understandable and tests needlessly more complicated.

Overall I have found it to be very much not worth it adding typer as a dependency. Hard pass.

On the other hand, I've switched to using Typer for most of my argument parsing because it's not an object I have to pass around. It lets me have the arguments co-located with the code, which is convenient. Especially for more complicated argument parsing, like one of my commands for our deploy process which has maybe 15 sub-commands, that sort of parsing with argparse is kind of a nightmare.

The solution to this kind of issue is something like parameters (See for example https://www.gnu.org/software/guile/manual/html_node/Paramete...). They are also thread safe. One can easily set them in tests without having to mock things. I am not sure it is possible to even have something like this in Python. Have not seen it anywhere in Python.

> Passing arguments to functions is thread-safe, but that soon becomes tedious when there’s more than a few or when they need to pass down through several layers of calls before reaching the point they should affect. Introducing a new setting to existing code is often easier with a parameter object than adding arguments.

But also, if you really wanted to, you could set the argsparse object to a global variable and then import it everywhere else. So that is not a limitation.

My issue with argparse isn't that it's not global, it's that you have to create sub-parsers for multiple commands, and then add arguments to those subparsers. Those parsers are all typically defined in a central location, but copying arguments between those parsers as I define new commands can get them jumbled up because the sub-parser comes along with the argument:

    sub1 = [create subparser]
    sub1.add_argument('-x')
    sub2 = [create subparser]

If I copy "sub1.add_argument" and put it under "sub2", and forget to change "sub1" to "sub2", it is a hard to track down bug. I've had this happen a lot as the parser gets more complex.

Typer completely eliminates this potential bug, because the arguments are defined as type annotations in the sub-command function itself.

Gee if only there was a way to reuse logic within a program.

> arguments are defined as type annotations in the sub-command function itself

So you duplicate logic in your type definitions instead of as instructions. Whatever makes you happy i guess.

Notably, argparse is way faster than click/typer. If you just need a few —options it’s probably preferable.

Argparse also does not require tens of external libraries.

That right there is the real winner. I already get queasy when my dependency list gets too long. Invoking an extra collection for what is mostly developer quality of life is not a trade-off I like to make.