<br><br><div class="gmail_quote">On 31 July 2012 13:51, Benoist Laurent <span dir="ltr"><<a href="mailto:benoist@ibpc.fr" target="_blank">benoist@ibpc.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div>Le Jul 31, 2012 à 1:45 PM, Oscar Benjamin a écrit :</div><div class="im"><br><blockquote type="cite"><br><br><div class="gmail_quote">On 31 July 2012 12:03, Benoist Laurent <span dir="ltr"><<a href="mailto:benoist@ibpc.fr" target="_blank">benoist@ibpc.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Finally.<div><br></div><div>The code I proposed doesn't work in this case: if you add any positional argument to one of the subparsers, then the parsing doesn't work anymore.</div>

<div>The reason seems to be that argparse thinks the last argument of the first parser is the last but one argument.</div><div>Hence, if a subparser takes some arguments, it fails.</div><div><br></div><div>Example: if the "-n" argument of the foo parser is set mandatory (so becomes "n" instead of "-n")</div>

<div><div><br></div><div><div>python toto.py foo.txt bar.txt foo 10</div><div>usage: toto.py [-h] [fname [fname ...]] command ...</div><div>toto.py: error: argument command: invalid choice: '10' (choose from 'foo', 'bar')</div>

</div></div></div></blockquote><div><br></div><div>What about:</div><div><br></div><div>$ python toto.py foo.txt bar.txt foo -n 10</div><div><br></div><div>Note that contrary to what you said above, your program does not work like a "standard unix tool". A standard command line program to do what you want would normally look like</div>
</div></blockquote><div><br></div></div><div>You're right.</div><div>But then, using argparse, I would have to add the same argument to all my subparsers since argparse does the work sequentially: once it recognized the start of a subparser, everything that follows have to be an argument of this subparser.</div>
<div>Hence, arguments (therefore options) from the main parser are not recognized anymore.</div></div></div></blockquote><div><br></div><div>If the parsing after the subcommand is to be the same for each subcommand, then don't use subparsers. You could just make the first argument be the command name and use one parser for everything.</div>
<div><br></div><div>If the parsing is supposed to be different for different subcommands then use subparsers and add the files argument to each subparser; you can make a function to add the common arguments and options if you don't want to duplicate the code.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Well I guess it is a intrinsec limitation: I think it's quite natural that the user can't enter a filename named as a command.</div>
</div></div></blockquote><div><br></div><div>There is an intrinsic limitation on any parser that it must be possible to determine the targets of the arguments uniquely. If you want the parser to scan through and take the first argument matching 'foo' or 'bar' and parse the remaining arguments accordingly then you already have your solution. It just won't work if the user wants to pass in a file called 'foo' or 'bar' (maybe that's acceptable, though).</div>
<div><br></div><div>The standard way, however, is to have a parser that takes the first non-option argument as a subcommand name and parses the remaining arguments according to that subcommand. Your command line users are more likely to be able to understand how to use the program if it works that way.</div>
<div><br></div><div>Oscar.</div></div>