On Tue, 28 Apr 2015 at 19:16 Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Apr 29, 2015 at 11:55 AM, Yann Kaiser <kaiser.y...@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 >
-- https://mail.python.org/mailman/listinfo/python-list
