Barry Warsaw writes: > Also as a general rule, I think we want just one level of > subcommand, so that `mmclient show --list` would be the template. > (That's open to discussion.)
I wonder about this in the context of argparse and the command line, because argparse makes a strong distinction (and corresponding associations) between *required positional* arguments and *optional* keyword-like arguments (ie, any argument with leading dashes). In the model Rajeev has shown so far, the "scope" argument (list, domain, user) hasn't been optional. > mmclient set --key <name> --value <value> This seems unnecessarily verbose on the one hand, and to not actually correspond to an actual use case, on the other: there's no scope mentioned. I feel the scope should be mandatory, even if it's sitewide: mmclient set --site-wide --key CAN_PERSONALIZE --value No mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes (after the first one, the second would be an error, I guess, but in other cases a site-wide setting would be interpreted as a default). I guess this horse has already bolted the barn, but I wonder about a syntax like mmclient set --site-wide --key PERSONALIZE --value Permitted mmclient set --domain=python.org --key PERSONALIZE --value Permitted mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No for resource constraining settings. (Permitted could probably be an alias for False.) Steve _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9