On 26 November 2013 18:16, Eli Bendersky <eli...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
