Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Chris Angelico]

On Wed, Apr 29, 2015 at 11:55 AM, Yann Kaiser <kaiser.yann at gmail.com> wrote:
> I'm aware of the pattern, and I don't really like it, especially because it
> gets weird when multiple modules are involved. You'd have to import modules
> because they have a side-effect of adding stuff to a list rather than import
> things so that you can put them in a list. In addition, if Clize manages
> that list, it will be a global mutable object to take care of in tests and
> so forth. That'll be rather yucky.
> I like the straightforwardness of "names are imported or defined" -> "names
> are passed to run" (what is passed to run *is* what you get) rather than
> names are collected as side effect of this and that import then run looks at
> them (well, I could explore what all those imports are doing...).

Okay. That's a philosophical difference that I can understand. There
is some magic when the decorator hangs onto a reference, and
personally, I think it's worth it, but if you don't, that's fine. All
I'd need to do is have my own decorator that collects the functions up
into a list.

>> Can you put together a Clize equivalent? I'm pretty sure it's going to
>> be remarkably close to what I want.
>
>
> https://gist.github.com/epsy/fba26300fccb7e672729
>
> It is pretty much the same save for the result formatting (clize prints
> non-None results on its own then exits, although for your example I
> understand the extra format step is necessary)

I already hacked the output a bit compared to the original. Exact
details aren't a big deal. In the case of fore/database.py, the
precise formatting hardly matters; this is basically the bootstrapping
back end (when you have a completely empty database, the server won't
start, so you need to create yourself an account first), so it's okay
if it just prints out a tuple's repr.

> Annotated line numbers for "put": (PEP8 double-spacing increased the
> numbers, sorry)
>
> 1-6: Boilerplate: imports
> 16: Function signature
> 17-22: Documentation (parameter descriptions need to be in their own
> paragraph in Clize's default helper)
> 37-39: Defining a wrapper just for reformatting the result
> 42-43: defining the execution point and adding the result format decorator
>
> The result formatting could be better. Maybe run could be made not to exit
> upon success (but still upon failure) and return the evaluated value rather
> than print it, or apply decorators en masse. I definitely see the appeal in
> either.

Returning rather than printing would perhaps be nice in terms of
reducing the magic, but there's already some magic around (eg exiting
on failure; mine, since it chains through to argparse, exits on --help
or failure), so it's not a big deal.

So we're actually really REALLY close to each other here. This looks good!

ChrisA