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

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