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. >> 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 -- https://mail.python.org/mailman/listinfo/python-list
