Home Original page

[Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

Paul Moore p.f.moore at gmail.com
Tue Nov 26 19:42:32 CET 2013 
On 26 November 2013 18:16, Eli Bendersky <eliben at gmail.com> wrote:
> FWIW I'm not advocating a breaking behavior change here - I fully realize
> the ship has sailed. I'm interested in mitigation actions, though. Making
> the documentation explain this explicitly + adding an option to disable
> prefix matching (in 3.5 since we're past the 3.4 features point) will go a
> long way for alleviating this gotcha.

Prefix matching is pretty much the norm in my experience, so I don't
think it should surprise people in general. That's not to say that
being more explicit in the docs wouldn't be a good thing anyway. For
the "passing unknown parameters through" case, I think having a means
to disable prefix matching is good (and it's a reasonably important
use case).

It *does* seem to me to be obvious from the name that an alternative
method named "parse_known_args" is the way to disable prefix matching.
So I think it needs to be clearly documented that it *isn't* and
precisely what purpose it is intended to serve. And it definitely
doesn't do that at the moment.

My feeling is that the following changes would be good:

1. Clarify in the documentation of parse_known_args that the function
does not behave any differently from parse_args in terms of what
arguments it accepts (and explicitly give an example showing that
prefix arguments *are* consumed). This can be done for 3.4 as it
doesn't change functionality.
2. Add a keyword argument to parse_known_args that allows the user to
disable prefix matching (I'd suggest match_prefix with a default of
True). This would be for 3.5.

Paul
More information about the Python-Dev mailing list