Message151891
| Author |
ncoghlan |
| Recipients |
bethard, docs@python, ncoghlan, xmorel |
| Date |
2012年01月24日.10:40:12 |
| SpamBayes Score |
1.2994474e-07 |
| Marked as misclassified |
No |
| Message-id |
<1327401613.65.0.84994526555.issue13850@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
My specific suggestion is to have a dedicated "Quick Reference" section before the first example.
This section would be aimed at two groups of people:
- those wanting a quick overview of the features argparse offers them ("This looks complicated, what can it do for me?")
- those wanting a reminder of the exact spelling of various items ("I know what I want to do, and I know argparse can do it because I've done it before, but how do I tell argparse exactly what I want?")
Since the heart of argparse is the ability to map arguments to actions, I'd suggest the quick reference section actually lead with a table of "actions" that argparse natively supports, along with a final entry pointing to the information on custom actions (i.e. subclasses of argparse.Action).
Likely columns for this first table: Action Name, Description, Parameters
The "Parameters" column would span multiple lines, with one parameter and a brief description of the parameter on each line.
The second table could then just be a short summary of the various 'nargs' values.
Repeating the list of parameters to ArgumentParser in the quick reference section probably isn't necessary, and the short parameter descriptions in the actions table should suffice for add_argument(). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年01月24日 10:40:13 | ncoghlan | set | recipients:
+ ncoghlan, bethard, xmorel, docs@python |
| 2012年01月24日 10:40:13 | ncoghlan | set | messageid: <1327401613.65.0.84994526555.issue13850@psf.upfronthosting.co.za> |
| 2012年01月24日 10:40:13 | ncoghlan | link | issue13850 messages |
| 2012年01月24日 10:40:12 | ncoghlan | create |
|