[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg added the comment: > While optparse that it isn't being developed further, therebut will not > be taken away. IIRC the reason for this was that it too had become > difficult to build out and that is what necessitated the creation of > argparse -- there wasn't clean way to add

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Raymond Hettinger added the comment: > we should undo the deprecation of optparse in the documentation > (https://bugs.python.org/issue37103), since the stated justification > for that deprecation was that optparse will not be developed further. While optparse that it isn't being developed

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg added the comment: If argparse will not be developed further to fix this bug, then we should undo the deprecation of optparse in the documentation (https://bugs.python.org/issue37103), since the stated justification for that deprecation was that optparse will not be developed

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Tom Karzes added the comment: If it's going to be closed, it should at least be acknowledged that it *is* a fundamental design flaw, stemming from the misguided goal of trying (and necessarily failing) to allow options to be freely intermixed with positional arguments, which of course can't

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Clint Olsen added the comment: I think this should serve as a cautionary tale that while (POSIX) standards aren't always the best of solutions, they are often made for good reasons, and special care should be taken when you decide to deviate from them. Otherwise it just causes frustration.

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Raymond Hettinger added the comment: > I believe that the behavior is so deeply ingrained in how argparse > works that it can't be changed. I think so as well. Handling arguments with a dash prefiew could be viewed as fundamental design flaw except for the fact that the module has been so

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric V. Smith added the comment: @karzes: If you read all of the messages above, you'll find that the behavior is deeply baked in to argparse. So, no, there is no fix for this issue. I'm not sure about others, but I believe that the behavior is so deeply ingrained in how argparse works that

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Tom Karzes added the comment: Is there *still* no fix for this? I keep running into this bug. People sometimes say "oh, it's no problem, just use = to associate the option value with the option name". That is so sad. It's basically saying "it can't be made to work the way it should, so

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by gaborjbernat : -- nosy: +gaborjbernat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Socob <206a8...@opayq.com>: -- nosy: +Socob ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Géry : -- nosy: +maggyero ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Orivej Desh : -- nosy: +orivej ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Raymond Hettinger : -- assignee: bethard -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg added the comment: porton: Please don’t steal someone else’s issue to report a different bug. Open a new issue instead. -- title: argparse: add a full fledged parser as a subparser -> argparse does not accept options taking arguments beginning with dash (regression

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

EV added the comment: I have an issue with the assumption that if all parameters are forced to be prepended by -- instead of only one dash, that you would then convert the -- to a single dash and have issues with single-dashed strings, when all other parameters are dual-dashed. This is

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: I attached a script that implements Evan's _match_argument idea, using a ArgumentParser subclass. I think this is the safest way to add different functionality to the parser. It (subclassing) is used, for example in pypi extensions like plac.

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Tom Karzes added the comment: Here's my situation: I originally used optparse, although some of the guys I worked with at the time were starting to use argparse. At first I thought, I'm sticking with optparse, it's more standard than argparse and probably better

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric V. Smith added the comment: I tend to agree with you about pre-scanning the arguments to find options. But at this point, our options to change the code are limited. The last time I looked at this (and it's been years), I came to the conclusion that the argument

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Tom Karzes added the comment: I'm dismayed to see that this bug was reported in 2010, yet as of January 2018 has not yet been fixed. This option parsing behavior is contrary to Unix option passing conventions. I certainly don't mind enhancements, but the last thing that

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: In the recently pushed, https://bugs.python.org/issue14191, "argparse doesn't allow optionals within positionals" we added new parsing functionality by defining a new parser method: parse_intermixed_args It added functionality without requiring

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Raymond Hettinger added the comment: Steven, do you care to put this to rest? -- assignee: -> bethard nosy: +rhettinger ___ Python tracker

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Evan Driscoll added the comment: One last comment for the time being. I actually think *both* changes are valuable. Fixing the bug, well, fixes the bug if you can set the appropriate flag. The improved error message still helps for existing code and new code that *doesn't*

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Evan Driscoll added the comment: > I also think that nargs=## could maybe be special-cased to just ignore > the A/O designation completely and only check there are enough, but I > haven't tried this out. Does this seem like a viable approach? Would a > patch that does that,

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Evan Driscoll added the comment: I ran into this issue today. (Or rather a couple weeks ago, and I just diagnosed it today.) Reading through the thread and from the bug's age it looks like a fix is probably not to promising, but Cherniavsky Beni's 2016-04-11 22:03 comment

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Change by Evan Driscoll : -- nosy: +evaned ___ Python tracker ___ ___ Python-bugs-list

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: Clint, the problem is the argparse uses different argument allocation method than optparse. optparse gives the '--subscipt_args` Action all of the remaining strings, and says - 'consume what you want, and return the rest'. So you consume up to (and including) the

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Clint Olsen added the comment: Thanks for the suggestion! It seems to be extremely limited, unfortunately. I don't want option processing to cease once I hit this switch. p=argparse.ArgumentParser() p.add_argument('--subscipt_args', nargs='...') #p.add_argument('pos',nargs='*')

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: Clint, 'nargs=argparser.REMAINDER' ('...') may do what you want p=argparse.ArgumentParser() p.add_argument('--subscipt_args', nargs='...') p.add_argument('pos',nargs='*') p.parse_args('--subscipt_args --foo --bar --baz -- other args'.split())

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Clint Olsen added the comment: I'm not sure if this is applicable to this bug, but one feature missing from argparse is the ability to snarf arbitrary options up to a terminating '--'. The purpose of this is to collect arguments for potential children you may spawn. An example:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by SpaceOne : -- nosy: +spaceone ___ Python tracker ___ ___ Python-bugs-list

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Martin Panter added the comment: My main concern with the patch is that it only half fixes the problem. It sounds like it will allow parsing “--opt -x” (if “-x” is not registered as an option), but will still refuse “--opt -h”, assuming “-h” is registered by default. What is the barrier to

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Cherniavsky Beni added the comment: +1, is there anything missing to apply Paul's patch? Can I additional suggest a change to the error message, e.g.: $ prog --foo -bar prog: error: argument --foo: expected one argument (tip: use --foo=-bar to force interpretation as argument of --foo)

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Memeplex added the comment: Here is another manifestation of this problem: http://bugs.python.org/issue17050 -- ___ Python tracker ___

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Memeplex added the comment: What's missing for this patch to be applied? Can I help somehow? -- nosy: +memeplex ___ Python tracker ___

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: http://bugs.python.org/issue22672 float arguments in scientific notation not supported by argparse is a newer complaint about the same issue. I've closed it with link to here. -- ___ Python tracker rep...@bugs.python.org

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Eric V. Smith e...@trueblade.com: -- versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: This patch makes two changes to argparse.py ArgumentParser._parse_optional() - accept negative scientific and complex numbers - add the args_default_to_positional parser option _negative_number_matcher only matches integers and simple floats. This is fine for

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: I think the `re.compile(r'^-.+$')` behavior could be better achieved by inserting a simple test in `_parse_optional` before the `_negative_number_matcher` test. # behave more like optparse even if the argument looks like a option if

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: If nargs=2, type=float, an argv like '1e4 -.002' works, but '1e4 -2e-3' produces the same error as discussed here. The problem is that _negative_number_matcher does not handle scientific notation. The proposed generalize matcher, r'^-.+$', would solve this, but

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Evgeny Kapun added the comment: The way how argparse currently parses option arguments is broken. If a long option requires an argument and it's value isn't specified together with the option (using --option=value syntax), then the following argument should be interpreted as that value, no

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric V. Smith added the comment: Evgeny: I completely agree. It's unfortunate that argparse doesn't work that way. However, I think it's too late to change this behavior without adding a new parser. I don't think existing argparse can be changed to not operate the way it does, due to

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: We need to be careful about when or where _negative_number_match is changed. We basically do: parser = argparse.ArgumentParser(...) parser._negative_number_matcher = re.compile(r'^-.+$') This changes the value for the parser itself, but not for the groups

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: While parser._negative_number_matcher is used during parser.parse_args() to check whether an argument string is a 'negative number' (and hence whether to classify it as A or O). parser._optionals._negative_number_matcher is used during parser.add_argument() to

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Evgeny Kapun abacabadabac...@gmail.com: -- nosy: +abacabadabacaba ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Daniel Shahaf pyt...@danielsh.fastmail.net: -- nosy: +danielsh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Tim Cuthbertson tim3d.j...@gmail.com: -- nosy: +gfxmonk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard added the comment: Interesting idea! The regex would need a little extra care to interoperate properly with prefix_chars, but the approach doesn't seem crazy. I'd probably call the constructor option something like args_default_to_positional (the current behavior is essentially

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Christophe Guillon added the comment: As a workaround for this missing feature, the negative number matching regexp can be used for allowing arguments starting with '-' in arguments of option flags. We basically do: parser = argparse.ArgumentParser(...) parser._negative_number_matcher =

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Andrew McNabb amcn...@mcnabbs.org: -- nosy: +amcnabb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

James B skilletau...@gmail.com added the comment: I have encountered this issue(python 2.7) with respect to positional arguments that begin with a dash (linux/ bash). In the following example, the parser requires three positional arguments. I attempted to encase the arguments in single-quotes

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: James: That’s not related to this issue. This issue is about options taking arguments beginning with dash (such as a2x --asciidoc-opts --safe, where --safe is the argument to --asciidoc-opts), not positional arguments beginning with dash.

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: Thanks for the analysis Eric. Yeah, it does seem like it's not possible to implement this feature request while still supporting optionals with variable number arguments. @andersk: Would the restriction to only having flags with a

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: @andersk: Would the restriction to only having flags with a fixed number of arguments be acceptable for your use case? I think that’s fine. Anyone coming from optparse won’t need options with optional arguments. However, FWIW, GNU

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: [I doubt my terminology is exactly correct in this post, but I've tried my best to make it so.) The more I think about this the more I realize we can't implement a parser that doesn't make guesses about '-' prefixed args and that works with

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: Maybe dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one should actually be a new class, e.g. parser = AllowFlagsAsPositionalArgumentsArgumentParser() Then you just wouldn't provide parse_known_args on that

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: Without guessing which args are options, I don't see how it's possible to implement parse_known_args(). I'd propose raising an exception if it's called and dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one (or whatever it

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: Steven: Yes, the current structure of the first pass scan makes any patch problematic. It really would be an implementation of a different algorithm. I'm still interested in looking at it, though. --

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: Yeah, I agree it's not ideal, though note that basic unix commands have trouble with arguments staring with dashes: $ cd -links-/ -bash: cd: -l: invalid option cd: usage: cd [-L|-P] [dir] If you're working with a file on a filesystem,

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Éric Araujo mer...@netwok.org added the comment: Documenting “--extra-args=--foo” or “--extra-args -- --foo” (untested, but should work) seems good. -- nosy: +eric.araujo stage: unit test needed - needs patch versions: +Python 2.7, Python 3.1, Python 3.2

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: -- won't work. Traditionally, this has been used to separate optional arguments from positional arguments. Continuing the cd example, that's what would let you cd into a directory whose name starts with a hyphen: $ cd -links-/ -bash: cd: -l:

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: There are some problems that ‘=’ can’t solve, such as options with nargs ≥ 2. optparse has no trouble with this: parser = optparse.OptionParser() parser.add_option('-a', nargs=2) parser.parse_args(['-a', '-first', '-second']) (Values at

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: Good point, I hadn't thought of that. Maybe ArgumentParser needs a don't try to be so helpful, parse like optparse option. Which is what Steven suggested earlier, I believe. I'd take a crack at this if there's general consensus on that

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: That would be a good first step. I continue to advocate making that mode the default, because it’s consistent with how every other command line program works[1], and backwards compatible with the current argparse behavior. As far as

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: I'd also like to see this as the default. After all, presumably we'd like Python scripts to work like all other command line programs, and I too am unaware of any other option parsing library that works the way argparse does. But changing

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: I don't think there's any sense in un-deprecating optparse because: (1) It's only deprecated in the documentation - there is absolutely nothing in the code to keep you from continuing to use it, and there are no plans to remove it

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Éric Araujo mer...@netwok.org added the comment: s/2.4/3.4/ s/2.5/3.5/ obviously :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by David Benjamin david...@mit.edu: -- nosy: +davidben ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list mailing

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: (1) It's only deprecated in the documentation Which is why I suggested un-deprecating it in the documentation. (I want to avoid encouraging programmers to switch away from optparse until this bug is fixed.) # proposed behavior parser =

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: @Éric: yes, thanks! @Anders: The reason the current implementation gives you the behavior you don't want is that the first thing it does is scan the args list for things that look like flags (based on prefix_chars). It assumes that

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Gerard van Helden dremel...@gmail.com added the comment: The reporter imho is 100% right. Simply because of the fact that in the current situation, there is no way to supply an argument starting with a dash (not even for instance a filename). That is, of course, total nonsense to be dictated

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Eric Smith e...@trueblade.com added the comment: While I also dislike the existing behavior, note that you can get what you want by using an equal sign. import argparse parser = argparse.ArgumentParser(prog='a2x') parser.add_argument('--asciidoc-opts', ... action='store',

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: It *would* be a backwards incompatible change. Currently, if I have a parser with both a --foo and a --bar option, and my user types --foo --bar, they get an error saying that they were missing the argument to --foo. Under your

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com 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. Either the user really wanted --bar, and the parser

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: arguments = *(positional-argument / option) [-- *(positional-argument)] positional-argument = string option = foo-option / bar-option foo-option = --foo string bar-option = --bar Er, obviously positional arguments before the first

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Steven Bethard steven.beth...@gmail.com added the comment: Note that the negative number heuristic you're complaining about doesn't actually affect your code below. The negative number heuristic is only used when you have some options that look like negative numbers. See the docs for more

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: Note that the negative number heuristic you're complaining about doesn't actually affect your code below. Yes it does: import argparse parser = argparse.ArgumentParser(prog='a2x') parser.add_argument('--asciidoc-opts', ...

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

New submission from Anders Kaseorg ande...@mit.edu: Porting the a2x program to argparse from the now-deprecated optparse subtly breaks it when certain options are passed: $ a2x --asciidoc-opts --safe gitcli.txt $ ./a2x.argparse --asciidoc-opts --safe gitcli.txt usage: a2x [-h] [--version] [-a

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list mailing

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

R. David Murray rdmur...@bitdance.com added the comment: It seems like reasonable request to me to be able to allow such arguments, especially since optparse did and we want people to be able to use argparse as a replacement. Though in general I find argparse's default behavior more useful.

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Nelson Elhage nelh...@nelhage.com added the comment: For what it's worth, I have trouble seeing this as anything but a bug. I understand the motivation of trying to catch user errors, but in doing so, you're breaking with the behavior of every other option parsing library that I'm aware of,

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Anders Kaseorg ande...@mit.edu added the comment: Though in general I find argparse's default behavior more useful. I’m not sure I understand. Why is it useful for an option parsing library to heuristically decide, by default, that I didn’t actually want to pass in the valid option that I

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

Changes by Greg Brockman g...@ksplice.com: -- nosy: +gdb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list mailing list

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

R. David Murray rdmur...@bitdance.com added the comment: Well, even if you call it a bug, it would be an argparse design bug, and design bug fixes are feature requests from a procedural point of view. -- ___ Python tracker rep...@bugs.python.org