Anders Kaseorg <ande...@mit.edu> added the comment: > I still disagree. You're giving the parser ambiguous input. If a > parser sees "--foo --bar", and "--foo" is a valid option, but "--bar" > is not, this is a legitimately ambiguous situation.
There is no ambiguity. According to the way that every standard option parsing library has worked for decades, the parser knows that --foo takes an argument, so the string after --foo is in a different grammatical context than options are, and is automatically interpreted as an argument to --foo. (It doesn’t matter whether that string begins with a dash, is a valid argument, might become a valid argument in some future version, looks like a negative number, or any other such condition.) arguments = *(positional-argument / option) [-- *(positional-argument)] positional-argument = string option = foo-option / bar-option foo-option = "--foo" string bar-option = "--bar" This is just like how variable names in Python are in a different grammatical position than keyword argument names, so that Popen(shell) is not confused with Popen(shell=True). This is not ambiguity; it simply follows from the standard definition of the grammar. argparse’s alternative interpretation of that string as another option does not make sense because it violates the requirement that --foo has been defined to take an argument. The only justification for considering that input ambiguous is if you start assuming that argparse knows better than the user (“the user accidentally forgot to type the name of the conf file”) and try to guess what they meant. This violates the user’s expectations of how the command line should work. It also creates subtle bugs in scripts that call argparse-based programs (think about call(["program", "--foo", foo_argument]) where foo_argument comes from some complex computation or even untrusted network input). > Changing the default behavior is really a non-starter unless you can > propose a sensible transition strategy (as is always necessary for > changing APIs in backwards incompatible ways). This would not be a backwards incompatible change, since every option that previously parsed successfully would also parse in the same way after the fix. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9334> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
