<div dir="ltr"><div class="gmail_quote">On Mon, 27 Apr 2015 at 17:04 Chris Angelico <<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 27, 2015 at 7:02 PM, Yann Kaiser <<a href="mailto:kaiser.yann@gmail.com" target="_blank">kaiser.yann@gmail.com</a>> wrote:<br>
> Hello everyone!<br>
><br>
> After a few years in development, I am proud to say Clize is landing its<br>
> feet again and is now in beta for an upcoming release.<br>
><br>
> You can try it out using    pip install --user clize=3.0b1    and you can<br>
> browse the docs at    <a href="https://clize.readthedocs.org/" target="_blank">https://clize.readthedocs.org/</a><br>
><br>
> For those who'd like an explanation before clicking links, here's Clize's<br>
> 5-bullet point explanation:<br>
><br>
> * Command-line interfaces are created by passing functions to `clize.run`.<br>
> * Parameter types are deduced from the functions' parameters.<br>
> * A ``--help`` message is generated from your docstrings. (Why does this<br>
> still need to be a bullet point?)<br>
> * Decorators can be used to reuse functionality across functions.<br>
> * Clize can be extended with new parameter behavior.<br>
<br>
Interesting. I've also been working on a simpler arg handling module;<br>
maybe we can work together. The goals for mine are:<br>
<br>
* Each function should be as independent as possible.<br></blockquote><div><br></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>In Clize, commands are also just regular functions which have the desired amount of keyword-only parameters and annotations. They can still be run individually, be tested, and so forth.</div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Minimize repetition (of names, descriptions, etc)<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>I try to minimize repetition, but the reality of things is that a parameter name could be repeated up to 4 times in Clize:</div><div><br></div><div>* In the function's parameter list</div><div>* In the function's docstring</div><div>* If named explicitly, in a @-kwoargs decorator (not needed with Py3)</div><div>* In an annotate decorator (again, not needed with Py2 compatibility isn't desired)</div><div><br></div><div>Two of these wouldn't be relevant in a Python 3-only world (if it's just a shell script replacement, you can probably pretend to be in one for a moment), the remainder being normal things in a function. So I'm not doing too badly there. Descriptions are of course only written in the description :-)</div><div><br></div><div>In addition, I took up the goal of helping minimize repetition in client code behavior through better support for decorators (which is really cool, by the way!)</div></div></div><div dir="ltr"><div class="gmail_quote"></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Keep everything in the function signature<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>I started taking this at heart with 3.0, after seeing the rather disgusting constructs that had to be used in Clize 2.x for specifying aliases and value converters. Now everything is annotations. Nothing in the docstring specifies behavior, and it isn't even read at all until --help is triggered. I intend to keep docstrings behavior-free because, well, they're strictly for documentation IMO.</div><div><br></div><div>One of the last remains of the old "give parameters to Clize about what your function's parameters does" stuff, a flag to pass the executable name to the function that's being run, was in fact changed in 3.0b1 to be an annotation instead, giving it more flexibility (you can annotate whichever parameter you want rather than being forced to use the first one).</div><div><br></div><div>What I mean to say, is that I am definitely committed to keeping everything in the function signature. Probably even more than you :-)</div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Simplify the basic and obvious usages<br></blockquote><div><br></div><div>That's where Clize started and I intend to keep simple usages simple.</div><div>One could say having to use @autokwoargs for turning parameters with default values into keyword-only parameters, but I feel it was necessary for consistency with the presence of actual keyword-only parameters.</div><div> </div><div>Overall we're agreed on all these goals.</div><div><br></div><div>I will add that I'm taking up extensibility as a goal as of Clize 3.0. clize.parameters.argument_decorator[1] wasn't originally by idea and was first implemented by someone else using the public API.</div><div><br></div><div>[1] <a href="http://clize.readthedocs.org/en/latest/compositing.html#using-a-composed-function-to-process-arguments-to-a-parameter">http://clize.readthedocs.org/en/latest/compositing.html#using-a-composed-function-to-process-arguments-to-a-parameter</a></div><div><br></div><div>What it's clearly lacking when compared to your parser is better docstrings, haha :-) The parser docs alleviate that a bit, but the parser can be hard to navigate at first.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://github.com/Rosuav/docstringargs" target="_blank">https://github.com/Rosuav/docstringargs</a><br>
<a href="https://pypi.python.org/pypi/docstringargs/" target="_blank">https://pypi.python.org/pypi/docstringargs/</a><br>
<br>
There's a demo file in the source repo, plus here are a couple of<br>
actual usage examples:<br>
<br>
<a href="https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py" target="_blank">https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py</a><br>
<a href="https://github.com/MikeiLL/appension/blob/master/fore/database.py" target="_blank">https://github.com/MikeiLL/appension/blob/master/fore/database.py</a><br>
<br>
The latter is an existing module in an existing project, and it grew a<br>
command-line interface with minimal changes, eg:<br>
<br>
<a href="https://github.com/MikeiLL/appension/commit/566f195" target="_blank">https://github.com/MikeiLL/appension/commit/566f195</a><br>
<br>
Can we merge our plans and make a single module that's more likely to<br>
be maintained long-term? No point over-duplicating!<br></blockquote><div><br></div><div>Agreed. I'm open to have more maintainers and to take input, but I have to admit that at this stage of development, I'm quite attached to Clize's existing codebase and features (although I'm always open to refactoring, and the test suite helps with that).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ChrisA<br>
--<br>
<a href="https://mail.python.org/mailman/listinfo/python-list" target="_blank">https://mail.python.org/mailman/listinfo/python-list</a><br>
</blockquote></div></div></div></div>