[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: See also issue 15258 which points out issues with the converse case. Further testing and development also discovered that in certain error cases, the help message produced by t18-equivalent code was incorrect. t18a.py is an update/rewrite (same concepts, tho

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: Of course, if a "real" solution can only be shipped in 3.3, it may want to use a different API than parse_args to avoid the parameter, parse_intermixed_args, perhaps. But my t18.py uses the name parse_args, but just always does the intermixed parsing, so tha

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: Sad. That means all the documentation of workarounds needs to be written, even figured out in the first place. Steven's code, while being a nice implementation when proper arguments are provided, produces inappropriate errors, because only the positional,

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

R. David Murray added the comment: To answer Glenn's procedural question: no this is not a bug whose fix can be backported. API changes are not allowed in maintenance releases. Doc improvements can be backported, though, so I'm leaving versios alone (alternatively someone could split this i

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: *Very* interesting, Steven. Looking again at section 15.4.6, and recognizing that positional arguments were never parsed by optparse, then we discover that with two minor tweaks, removing "and add additional ArgumentParser.add_argument() calls for the positi

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Steven Bethard added the comment: Actually, that could be even simpler: args, remaining_args = optionals.parse_known_args() args = positionals.parse_args(remaining_args, args) -- ___ Python tracker __

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Steven Bethard added the comment: Thinking about it a bit more, it strikes me that maybe you could get the behavior you want by declaring two parsers, one with just optionals, and one with just positionals. Then: optional_args, remaining_args = optionals.parse_known_args() args = positionals.

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: Ah yes, argparse had a life outside the stdlib, so now I understand your compatibility concerns. Mind you, I think the overall technology of argparse is superior to optparse, which is why, together with the optparse deprecation, I am trying to port to use i

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Steven Bethard added the comment: > Hence, I conclude that, unless this was spelled out in the PEP and I > missed it, that having such boundaries is a bug Practically speaking, we just can't change this because it will break existing argparse scripts. Argparse has had this behavior since 2006

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: Improved documentation would certainly help the situation. And yes, I understand that optparse simply returned the set of positional parameters without giving them names, types, or groups. So does getopt, and pretty much all previous art in the arena of com

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Steven Bethard added the comment: > optparse, which argparse attempts to replace, permitted positional > arguments to be intermixed with optional arguments Sure, but optparse didn't actually parse positional arguments - it just threw them into a bag, and then you had to group them and convert

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Glenn Linderman added the comment: Interesting that the behavior is intentional, yet it accepts positional parameters either before, or after, or between optional (flag) parameters. This seems to me to be a case where proper documentation of the intention would have led to the realization tha

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

guilherme-pg added the comment: I uploaded an incomplete patch that might address the issue so it can be discussed. This patch introduces 'greedy_star', a new constructor parameter to ArgumentParser that makes "*" positional arguments behave as expected in the test case. The patch doesn't y

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Steven Bethard added the comment: This behavior is intentional - positional arguments must be sequential, not broken up with optional (flag) arguments between. So this is a documentation bug. Allowing positional arguments to be broken up with optional (flag) arguments between them would be a

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

Changes by Éric Araujo : -- nosy: +bethard title: argparse: nargs='*' doesn't parse all positional parameters -> argparse: nargs='*' doesn't get out-of-order positional parameters versions: +Python 2.7, Python 3.3 ___ Python tracker