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

[Yann Kaiser]

On Tue, 28 Apr 2015 at 19:16 Chris Angelico <rosuav at gmail.com> wrote:

> 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.
>

Yeah, writing that feature is fairly easy. Telling users why their commands
aren't registered or why their circular import loop is blowing up isn'it.


> >> 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!
>

Indeed :-)


> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150429/c72cde7a/attachment.html>