3 ms·
I wonder whose problems this solves. I have a handful of scripts with miniscule CLI handling (usually len(sys.argv) is enough) - so it's 3 loc instead of 5? T
by wink 10y ago
I wonder whose problems this solves.
I have a handful of scripts with miniscule CLI handling (usually len(sys.argv) is enough) - so it's 3 loc instead of 5?
Then I have a moderate amount of scripts where using click or optparse makes sense.
Just looked up one tool, there's exactly 12 lines (including import, ignoring linebreaks) to handle 6 different CLI args. I could use fire. Less code, more "magic", less self-documenting excplicit code
Then there's this application with 15 @click.option() lines (don't ask, ran out of sensible single-char argument shorthands). Yes, it has an ugly main() with 15 keyword arguments, but I'd also have that with fire I guess. but here at least it's explicit again.
TLDR: Sounds absolutely nice on first skim, but I don't see why I would ever use this. Have I been writing so many CLI apps in python already that I exhibit stockholm syndrome towards click AND optparse? :)
- BerislavLopac 10y agoI've lately come to know and respect argparse. Click is nice and great, but can present an unnecessary burden if your script uses (intentionally or not) no other dependencies outside the standard library. And optparse is deprecated in Python 3.
- wink 10y agoOh yes, I'm strictly a Python 2 user (I know, I know).
- dbieber 10y agoAn excellent question. Certainly switching from argparse to Fire will usually only save you some small amount of code. But if your code is changing, that's when you'll start to see larger time savings. With Fire, your CLI will stay up to date without you having to update any parsing code.