|
Size: 1314
Comment: the goals of option parsing and description of current solutions
|
Size: 1476
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers on #pragma heading Option Parsing <<TableOfContents()>> |
|
| Line 3: | Line 8: |
| Overview of Python modules for option parsing: | === Builtin Tools === Overview of Python modules for option parsing |
| Line 9: | Line 16: |
| === External tools === | |
| Line 10: | Line 18: |
| External tools: | |
| Line 27: | Line 34: |
| See also ConfigParser. | == See Also == * ConfigParser * ConfigurationAndBuildTools |
1. Builtin Tools
Overview of Python modules for option parsing
getopt - procedural interface in stdlib for refugees from the C camp
optparse - stdlib name for Optik, a revolutionary API for option parsing in Python 2.x
argparse - optparse pumped up for Python 3.x (and included in Python 2.7)
2. External tools
3. The goal of option parsing
The option parsing goal can be split in two parts:
- identifying the command user needs to execute
- changing configuration for the program
For the first part, it will be good if option parsing library could handle 'subcommands'. It is known that 'argparse' can do this and 'optparse' cannot. 'docopt' probably handles this transparently.
For the second thing there should be some strategy to choose how (and which) options are merged into configuration to make the process of program configuration easy for the user and occasional patch contributors.