[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Andy Buckley a...@insectnation.org added the comment: The backward compatible solution is to have --help-options disabled by default, and ask people to enable it with add_interface=True. Or to add the option just before arg parsing, if it has not already been defined? Thanks for the patches, Filip! Andy -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
R. David Murray rdmur...@bitdance.com added the comment: I prefer an approach that allows this option to be defined by default, since if it is not defined by default it defeats part of the purpose of having the option. The program author may not be concerned with completions (or even know about them), but if the option is defined by default then even the programs of those authors can be auto-completed by the generic script. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
R. David Murray rdmur...@bitdance.com added the comment: Removing 2.7 since it is now in feature freeze. -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Steven Bethard steven.beth...@gmail.com added the comment: On Wed, Apr 21, 2010 at 12:36 AM, Andy Buckley rep...@bugs.python.org wrote: Or to add the option just before arg parsing, if it has not already been defined? Something like this was suggested before and it doesn't really work out well. It means the first time you call .parse_args(), your options get modified. So if you do anything with the parser before .parse_args() -- for example, calling .print_help() -- then you don't get the right options. On Wed, Apr 21, 2010 at 5:12 AM, R. David Murray rep...@bugs.python.org wrote: I prefer an approach that allows this option to be defined by default I agree that it would be best if all command line utilities supported this by default[1]. I'm just not sure how to do it in a backwards compatible way. The fact that the most recent patch against argparse has to modify so many test cases suggests that it's going to have unexpected consequences for a bunch of users. [1] Though I'd feel more confident in that belief if someone could point me to what the output of other programs that do this looks like so that I could see we were following a standard somewhere. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Steven Bethard steven.beth...@gmail.com added the comment: Thanks for the patch! One concern I have is that adding --help-options by default has the potential to break existing code, e.g. if someone using optparse or argparse was already defining their own --help-options flag. The backward compatible solution is to have --help-options disabled by default, and ask people to enable it with add_interface=True. Comments on the argparse patch: I think it's probably overkill to create InterfaceFormatter - just do the appropriate formatting in the _InterfaceAction. I also wouldn't add format_interface or print_interface until someone requests them. Last nit: don't add the takes_value method, just inline your self.nargs != 0 check in the one place you need it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Filip Gruszczyński grusz...@gmail.com added the comment: Patch for optparse with tests. If it's ok, I'll sit down to argparse. -- keywords: +patch Added file: http://bugs.python.org/file16985/4256_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Steven Bethard steven.beth...@gmail.com added the comment: Sorry, what does I'll sit down to mean? Does that mean you're offering to try to do the argparse patch too? Or that you'd rather someone else do it? (Either one's fine - I just couldn't tell which you meant.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Filip Gruszczyński grusz...@gmail.com added the comment: I guess I am using my English too little, that's why I am using polish expressions too often. What I meant was of course, that I will do argparse patch too. I haven't provided docs for --help-options yet, becuase it is not clear to me, it is an accepted feature. When it is, I will update the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Filip Gruszczyński grusz...@gmail.com added the comment: Ok, here comes patch for argparse too. -- Added file: http://bugs.python.org/file16996/4256_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Andy Buckley a...@insectnation.org added the comment:
Thanks for the pointers to both of these... I wasn't aware of either. I see
argparse has been recently approved for Python stdlib inclusion, too:
http://www.python.org/dev/peps/pep-0389/ Congratulations!
As far as I can tell, genzshcomp is parsing the output of the help command to
reverse-engineer what the allowed flags should be. Assuming that only one space
occurs between the arg and its metavar, this should work 99% or the time... I'm
not sure if there is any attempt to be clever when the formatting is ambiguous.
But given that the opt parser already contains the structured information, life
can be made easier by writing out a more readily parseable format.
Here's an example bash parser function and its usage, for a further-simplified
form of the above format where each arg (long or short) gets a line of its own
and the arguments are indicated by a separate word as in the current output:
Example input:
$ foo --help-options
#OPTPARSE_FORMAT 0
--version
-h
--help
-r REGEXP
--regexp REGEXP
-s N
--start N
-e M
--end M
-f FILE
--file FILE
and the parser/completion functions:
function _optparse_getargs() {
local opts cur prev
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
prev=${COMP_WORDS[COMP_CWORD-1]}
PREVIFS=$IFS
IFS=$'\n'
for line in `$1 --help-options | egrep '^-'`; do
opt=`echo $line | sed 's/^\(-[^ ]\+\).*$/\1/'`
argeq=`echo $line | sed 's/^--[^ ]\+ \([A-Za-z0-9]*\)$/=/'`
if [[ $argeq != = ]]; then argeq=; fi
opts=$opts $opt$argeq;
done
IFS=$PREVIFS
unset PREVIFS
opts=`echo $opts | sed -e 's/^ *//' -e 's/ *$//'`
if [[ ${cur} == -* ]] ; then
COMPREPLY=( $(compgen -W ${opts} -- ${cur}) )
if test -n $COMPREPLY; then
return 0
fi
fi
return 0
}
function _foo() {
_optparse_getargs foo
return 0
}
complete -F _foo -o default foo
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4256
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Andy Buckley a...@insectnation.org added the comment: That sort of idea, yes: just a wild thought, but it would be really nice if this was available so that in combination with a standard bash/zsh function, getting basic automatic command completion for scripts built with optparse (and any other implementer of such a scheme) was as simple as adding complete -F _optparse -o default mycmdname to the completion script library. The simple scheme you laid out seems fine to me, but in the best bikeshedding tradition it would be useful to distinguish between options which take an argument and those which don't, pre-empt the need for a format version, and make the parsing even easier by removing cosmetic whitespace, commas etc.: grusz...@gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help-options #OPTPARSE_FORMAT 0 --version -h --help -r= --regexp= -c= --contains= -s= --start= -e= --end= -f= --file= -t= --template= -p= --purge= Maybe this is just a pipe-dream, but the need to hand-write basic completion scripts seems so unnecessary, just for lack of any (even de-facto) standardisation. As optparse already enforces/encourages many good habits and conventions, some system like this would further help the integration with shell completion. Or maybe the existing --help output is good enough for a rather more fiddly standard bash completion parsing function. I've tried writing one of these, but it would hard for it be generally robust since the descriptive strings can contain any structure that they feel like, and could hence mess up the pattern-matching. I'm very happy if someone can out-sed me and make that work! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Filip Gruszczyński grusz...@gmail.com added the comment: I'll take a look at optparse code and try to provide a patch. But first holidays must finish and I must come back to ma usual residence, where I have programming environment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
R. David Murray rdmur...@bitdance.com added the comment: Please target argparse rather than optparse, or better yet in addition to optparse. And I'm +1 for making it easier to write completion scripts. -- nosy: +bethard, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Steven Bethard steven.beth...@gmail.com added the comment: Someone pointed this out to me earlier: http://pypi.python.org/pypi/genzshcomp I believe it's trying to solve the same problem, and claims to work with both optparse and argparse, so it might be worth looking into what it's doing and seeing if there's a useful patch that could be proposed for argparse. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Filip Gruszczyński grusz...@gmail.com added the comment: Are you saying, that for example for this: grusz...@gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help Usage: logbuilder [options] repo Options: --version show program's version number and exit -h, --helpshow this help message and exit -r REGEXP, --regexp=REGEXP filter revisions using regular expression -c CONTAINS, --contains=CONTAINS filter revisions that doesn't contain given string -s START_REV, --start=START_REV first revision to be used in log -e END_REV, --end=END_REV last revision to be used in log -f FILE, --file=FILE file where result will be stored -t TEMPLATE, --template=TEMPLATE template used to display changes -p PURGE, --purge=PURGE remove parts of a commit messages, that match given regexp you would like to get: grusz...@gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help-options --version -h, --help -r, --regexp -c, --contains -s, --start -e, --end -f, --file -t, --template -p, --purge ? -- nosy: +gruszczy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Changes by Daniel Diniz aja...@gmail.com: -- keywords: +easy priority: - normal stage: - test needed versions: +Python 2.7, Python 3.2 -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
New submission from Andy Buckley [EMAIL PROTECTED]: optparse is a great option parser, but one thing that would make it even greater would be if it provided a standard option (cf. --help) which lists all the available options in a parseable form. Something prefixed with --help, e.g. --help-options would be ideal since it doesn't clutter the option namespace. This would provide a simple command-line hook for e.g. bash completion customisation with complete/compgen, which could then easily and maintainably obtain the list of available switches via the --help-options flag rather than hard-coding the option names or attempting to grep the output of --help It would also be good if the OptionParser provided a simple Python API way to obtain the names of all option switches, rather than having to loop over OptionGroups, calling the unadvertised 'option_list' and 'get_option_name' methods! -- components: Library (Lib) messages: 75469 nosy: andybuckley severity: normal status: open title: optparse: provide a simple way to get a programmatically useful list of options type: feature request versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Changes by Winfried Plappert [EMAIL PROTECTED]: -- nosy: +wplappert ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
