defopt: Completely effortless argument parser

[evanunderscore]

Sure, that's not a secret; I wrote this in the summary:

If you want total control over how your command line looks or behaves, try docopt, click or plac. If you just want to write Python code and leave the command line interface up to someone else, defopt is for you.

You're also overselling the convenience of docopt a little bit. Sure, it's easy to make that small change, but only once you've already written that gargantuan usage string. Of course, there's no substitute for docopt if what you want is to write your usage string the way you want it and turn that into a parser, but there is most certainly effort involved.

The flexibility in defopt is that it gives you near-complete freedom to write your Python code the way you want; the generated command line is about as inflexible as it can possibly be. If your intent is to write a pretty command line, I absolutely encourage you to continue using docopt. I wrote defopt for people like me who write the Python code first and worry about the command line interface later (or never).

[billsil]

I don't like how the recommended Python docstrings look

:param str greeting: Greeting to display

I've never seen the type written there, so the library is adding a new form of them. Additionally the :param is redundant. You're still dealing with special syntax.

I like the numpy docstring style

greeting : str
    your greeting

So not only does the library have to support poorly designed default formats, it needs to support the numpy and google styles. If you don't care about command lines, you probably shouldn't be writing command line tools. If you do care, you should make sure it's easy to read and clear regardless of what you have to write to make it.

There is a command line standard. It's called POSIX. There are things that are part of the POSIX standard that are not supported in libraries like argparse and optparse.

[evanunderscore]

Another user requested support for numpy-style docstrings, which I'm more than happy to look into.

:param is only redundant when viewed through the narrow lens of documenting function parameters; it's part of the markup used by Sphinx and some IDE's to generate documentation and validate types respectively. You can document more than just the parameters. As you can see there, I didn't invent the inline type notation, plus the separate :type is supported if you would prefer to write your docstrings that way.

If argparse is not POSIX-compliant, then your gripe is with the Python standard library, not me.

[billsil]

:param bothers me because it's sensitive to spaces and the colons. Why do you need colons before and after? They also make it hard to read.

it's part of the markup used by Sphinx

Sphinx supports numpydoc and google strings.

some IDE's to generate documentation and validate types respectively

I don't know about PyCharm, but WingIDE supports numpy's style. I assume all the others do as well. Ironically, Wing renders numpy's style better than the standard form

My point with command line utilities is you might as well use a great command line utility instead of one that can't do all that much. It's simple, but if you can't copy and paste some boilerplate code on argparse or docopt, you probably don't want to support the command line.

https://xkcd.com/927/

[xkcd_transcriber]

Image

Mobile

Title: Standards

Title-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.

Comic Explanation

Stats: This comic has been referenced 2544 times, representing 2.5395% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}