4 ms·

Argparse is still a pretty solid choice, because it's so ubiquitous and well documented and fairly easy. Typer and Click are both very nice, with some good erg

Argparse is still a pretty solid choice, because it's so ubiquitous and well documented and fairly easy. Typer and Click are both very nice, with some good ergonomics, but I find Typer's "tutorial" style documentation to be rather hard to search to find answers to things like "What arguments does Typer.App() take?" I have a program I'm working on right now that does user-initiated argument parsing, and argparse is a great fit for it. I'd love to have a text-based UI as an option to drop users into, but Textualize requires Click (IIRC), and using Textual directly in my code to create the UI I've spent hours on and had absolutely no luck even getting started.

zelphirkalt 3y ago
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.
- linsomniac 3y ago
  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.
  - zelphirkalt 3y ago
    The solution to this kind of issue is something like parameters (See for example https://www.gnu.org/software/guile/manual/html_node/Parameters.html 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.
    - linsomniac 3y ago
      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.
      - voidnap 3y ago
        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.
pletnes 3y ago
Notably, argparse is way faster than click/typer. If you just need a few —options it’s probably preferable.
mkesper 3y ago
Argparse also does not require tens of external libraries.
- fbdab103 3y ago
  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.

zelphirkalt 3y ago

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.

linsomniac 3y ago
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.
- zelphirkalt 3y ago
  The solution to this kind of issue is something like parameters (See for example https://www.gnu.org/software/guile/manual/html_node/Parameters.html 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.
  - linsomniac 3y ago
    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.
    - voidnap 3y ago
      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.

pletnes 3y ago

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

mkesper 3y ago

Argparse also does not require tens of external libraries.

fbdab103 3y ago
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.