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

[Anders Kaseorg]

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 the desired features
> (subparsers, actions, etc).

My concern is not that optparse will be taken away.  My concern is that the 
documentation incorrectly discourages its use.

https://docs.python.org/3/library/optparse.html
“Deprecated since version 3.2: The optparse module is deprecated and will not 
be developed further; development will continue with the argparse module.”

Given that the apparent conclusion of this bug is that argparse has also become 
too difficult to fix, either argparse should be deprecated for exactly the same 
reason, or optparse should be un-deprecated.

Most programs don’t need the extra features of argparse, and optparse doesn’t 
have this bug, so optparse is a better default choice; the documentation should 
not be encouraging argparse over it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 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 the desired features (subparsers, actions, etc).


> If it's going to be closed, it should at least be acknowledged 
> that it *is* a fundamental design flaw

That seems a spiteful demand. It is more correct to say that the design met its 
original intended goals but unfortunately the structure of the first pass scan 
precludes cleanly handling arguments with dashes.  The limitations are noted in 
the docs in the section, "Arguments containing -". 

As Eric pointed out, there are alternative argument parsing packages available 
on PyPI.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Anders Kaseorg]

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 further.

The documentation should encourage programmers to use correct libraries, and 
optparse is correct here where argparse is not.  People who need the extra 
features of argparse and aren’t bothered by its incorrectness are welcome to 
decide to use it, but this is not the right default decision for the 
documentation to promote.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tom Karzes]

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 be done without dropping support for 
unrestricted string arguments.  This means that argparse does not, and 
apparently never will, support string argument values that begin with hyphens.  
Yes, I know that the equal sign can be used to handle *some* cases, but who 
wants to use equal signs to specify command-line options?  And there is no 
direct workaround for options that specify an nargs value of 2 or more.

Also, fixing this is *not* hard at all.  All that needs to be done is to add a 
keyword argument to the parser that tells it not to try to look ahead to find 
options, but to instead scan for them sequentially.  Just like any properly 
designed option parser does.  It's *easier* than trying to look ahead.

I have my own quick-and-dirty hack that approximates this, but it's ugly and 
disgusting, it only handles some cases, and I hate using it.  All the hack does 
is replace -- with a different prefix that I'm willing to avoid, then uses a 
different option prefix character so that the remaining strings starting with a 
single - are not seen as options.  This handles a single leading - in an option 
value.  It's not a general solution at all, but it's just barely good enough to 
solve my problem cases.

Yes, argparse has been successful, but the reason for that success is that it 
wasn't made for proficient users.  Rather, it was designed to cater to people 
who aren't very capable, and are perfectly happy to live with restricted string 
values if it means they can shuffle their command-line arguments willy nilly 
and still have it recognize them, rather than stopping when it should and 
giving the appropriate error.  It trades precision for ease of use.  This 
creates a vacuum for highly capable users who don't want to give up precise 
argument processing for the sake of a feature that's of no use to them in the 
first place.

Don't get me wrong.  There are a lot of nice features that argparse added which 
I find very useful.  The problem is it also sacrifices core functionality, 
making its predecessor, optparse, preferable for some applications.  In those 
cases, there is no transition path from optparse to argparse, since argparse 
does not handle all of the cases that optparse does.  And since argparse does 
not subsume the functionality of optparse, I find the decision to deprecate 
optparse highly questionable.

With optparse deprecated, Python no longer supports POSIX-compliant 
command-line option processing.  How is that a sound decision?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Clint Olsen]

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.

While argparse behavior has some convenience, it isn't a very good fit for a 
multi-layered scripting environments where arguments for subordinate programs 
need consideration.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 
successful (both before and after landing in the standard library).

I've come to believe that argparse is very difficult to change without risk of 
breaking many existing tools that depend on argparse working exactly the way it 
does now.

Also, this issue is over a decade old and no clear solution has emerged.


> at this point installing modules from PyPI is sufficiently easy
> that I'm not sure it makes sense to advocate for another command
> line parser in the stdlib.

I agree. It would be a hard sell at this point.

Let's close this one.  I don't think it is going to get solved.

--
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 it can't be changed. I have the same 
desire as you: to use a command line parser that works like all other Unix 
commands. I've switched my personal code to click. There's also Appeal, typer, 
and others.

Unlike when argparse was added to the stdlib, at this point installing modules 
from PyPI is sufficiently easy that I'm not sure it makes sense to advocate for 
another command line parser in the stdlib.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tom Karzes]

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 instead use = to introduce your option 
values."  I should *never* have to use = to introduce an option value.

And besides, using = doesn't even handle all cases.  For example, suppose I 
have an option that takes two string arguments, i.e. type=str and nargs=2.  Now 
I want to specify "-x" and "-y" as the two string arguments, like this:

--opt -x -y

As far as I can tell, argparse simply cannot handle this, and there's no 
workaround.  Using = doesn't solve this case.

One more time:  All I want to do is disable the undesirable option look-ahead.  
It is utterly and completely useless to me.  I want sequential, unambiguous 
option parsing.  You know, the way the entire rest of the world does it.  All 
that's needed is something that tells argparse to disable its look-ahead 
heuristic and to simply do what it's told.  Scan left-to-right.  If the next 
string is a recognized option name, then treat it as an option and take its 
arguments from the strings that follow, regardless of what they look like.  
Rinse and repeat.  That is how correct option parsing is done.

All this look-ahead heuristic does is cater to confused beginners, at the cost 
of breaking it for experienced users who know exactly what they want and are 
frustrated that argparse won't let them specify it.

By the way, is there any supported, competing alternative to argparse?  It 
seems like argparse is never going to support option values that begin with 
hyphens, so at this point I'm looking for an alternative that I don't have to 
fight every time I want to allow option values that begin with hyphens.  Maybe 
it's time to create a new option parsing package that supports the most useful 
argparse features, but doesn't mistake option values for option names.  You 
know, something more like optparse, but with some added features.  It just 
needs to support strict left-to-right option parsing.

At this point, I'm thinking it may be time to bite the bullet and write my own 
option parsing package.  One that actually works, and can't be deprecated.  But 
it seems like such a waste of time.  It's hard to fathom why Python no longer 
provides a working option parser.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[gaborjbernat]

Change by gaborjbernat :


--
nosy: +gaborjbernat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Socob]

Change by Socob <206a8...@opayq.com>:


--
nosy: +Socob

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Géry]

Change by Géry :


--
nosy: +maggyero

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Orivej Desh]

Change by Orivej Desh :


--
nosy: +orivej

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: bethard -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Anders Kaseorg]

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 from optparse)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[EV]

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 especially crazy if the user specifies that 
prefix_chars="--" when creating the parser! You wouldn't mix up ** with * just 
because it's a two char string, so why do this for -- in this day and age when 
parameters can take on very different and complicated structures?!

--
nosy: +fennec15

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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.

My version places the special nargs case after the default match test.  So it 
acts only if the regular action fails.  But I don't know of a test case where 
that difference matters.

I've tested it with all the examples posted in this issue, but have not tested 
it against test_argparse.py.  I'd also like to know if it goes far enough in 
adapting to optparse/POSIX usage.  It probably doesn't.

--
Added file: https://bugs.python.org/file47404/argparse_opt.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tom Karzes]

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 
supported.  But at some point optparse became documented as deprecated, with 
argparse being hailed as its replacement.

At that point my preference switched, again mostly because I wanted the most 
reliable, best supported option parsing package.  And yes, I have come to 
appreciate some of the features of argparse, but to me that takes a back seat 
to correct functionality.

The documentation for argparse promotes the idea that it completely subsumes 
optparse, and that applications that use optparse can easily be converted to 
use argparse.  And for the most part that's true, except that optparse 
identifies options correctly and argparse does not.  That really, really needs 
to be documented.

What I want is a supported, standard option parsing library that knows how to 
extract option values correctly.  I used to have that with optparse, but now I 
feel like the rug's been pulled out from under me.  optparse is supposedly 
deprecated, and argparse doesn't work.  So I either use a package that could be 
removed from Python distributions at any time, or I use a package that has 
dangerous bugs.  I don't find either alternative very attractive.

As I said, un-deprecating optparse would be sufficient, especially if people 
started adding some of the argparse functionality to it.  Creating a new 
package would work too.  But from what I've seen, it sounds like argparse is 
beyond hope of repair and will never work properly.  I.e., it's a dead-end 
development path.  So why isn't *argparse* deprecated?

I've always maintained that core functionality is of primary importance.  Shiny 
bells and whistles, no matter how useful, are of secondary importance.  In my 
opinion, the wrong package was deprecated.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 pre-scanning was sufficiently baked in to argparse that a separate 
traditional" mode was better done as a separate library.

But I lack the time and energy to research if there's an existing third party 
library that's acceptable, what it would take to enhance optparse, or write a 
new library.

It sounds like what you want is optparse, but with help in processing 
positional arguments. Is that a fair statement? Or is there some other feature 
of argparse that's preventing you from using optparse? I know for me it's help 
with positional arguments.

I think at some point we need to close this bug, because I don't see a way of 
modifying argparse to do what you (and I) want. paul.j3 explains several times 
in his messages on this thread that it's just how argparse fundamentally works.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tom Karzes]

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 should *ever* be introduced into an option parser is ambiguity.  
It's dangerous.

I'm an old-school Unix guy.  I know exactly what options I want to pass to my 
program, and I know exactly how they should be passed.  Options first, with 
option arguments immediately following the option name, followed by positional 
arguments (with no more options being recognized after that point).  If the 
first positional argument begins with a hyphen, "--" can be used to end option 
parsing.  That's all I want.  Simple.  Precise.  Unambiguous.  And it doesn't 
place any constraints on what an option value can look like.

Yes, I know I can get around the problem by using "=" to join option values to 
the preceding option names, but that shouldn't be necessary.

In my opinion, the entire approach of attempting to distinguish option names 
from arguments out of context is fatally flawed.  It cannot be done.  Period.  
Furthermore, it's utterly unnecessary.  All I want is a parameter I can pass to 
argparse to tell it to accept the entire command line at face value, without 
any second-guessing.  If I specify an option that takes an integer argument, 
then the very next command line argument should be an integer.  If it isn't, I 
want an immediate error.

More to the point, if I specify an option that takes a string argument, then 
the very next command line argument is that string, period.  It doesn't matter 
if it begins with a hyphen or any other character for that matter.  It's a 
string.  It can contain *any* character.  And yet, argparse doesn't support 
this basic, fundamental functionality without the user inserting an "=" to join 
the arguments.  Why??

Here's an analogy:  Your favorite car company has released a new car.  It adds 
lots of great features, like a sun roof and a fancy navigation system.  But 
oops, the brakes no longer work if you're turning right when you apply them.  
But not to worry!  You can always just throw it into park to stop the car.  
It's worth it for the new features, right?  Wrong.

It seems to me like there are three possible solutions to this:  (1) Add a 
"traditional" mode to argparse that completely bypasses any attempt to classify 
command line arguments as "options" vs. "arguments", (2) Un-deprecate optparse, 
and resume development on it, adding support for some of the argparse features 
but without breaking standard Unix option parsing, or (3) Create yet another 
new option parsing package for Python, one which supports traditional Unix 
option parsing and doesn't introduce gratuitous ambiguities and restrictions on 
what strings can contain.

My specific case:  I have an option whose argument is a comma-separated list of 
signed integers, as a single string.  This is the format another, non-Python 
application requires, and it needs to be compatible.  But the following fails:  
--myopt -1,2

Apparently it thinks "-1,2" is an option name.  No, it's a string option value, 
and should not be interpreted in any other way.  I want it passed as the option 
value.  I would want the same no matter *what* characters it contained.  And I 
don't want to have to glue the two arguments together with "=".

--
nosy: +karzes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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 a new parameter for the parser (no 
point in confusing users with parameters they don't need or understand).  It 
was also a good fit because it worked on top of the default parser, fidling 
with the nargs to parse positionals and options in different runs. 

I would like to see something similar for this problem.  Define a

parser.parse_opt_args() method 

that tries, as much as possible to follow the optparse strategy.  As I 
commented previously, the difference in behavior starts at the top.  

argparse distinguishes between flag (optiona) and argument strings based on the 
dash(es), and then allocates strings to the Actions based on that pattern and 
nargs.  It also alternates between handling positionals and optionals.

optparse passes all the remaining strings to an Action, lets it consume what it 
wants, and resumes parsing with the remainder.  It does not handle positionals; 
those are just accumulated in an 'extras' list (sort of like parse_known_args 
without any defined positionals).

An unknown in this approach is whether the argparse.Action class(es) can be 
adapted to this 'consume what you want' strategy.  It would be nice if such an 
alternative parser could be written that doesn't require any changes to the 
Action.  We don't have to go so far as to allow custom Action classes that 
imitate optparse Options.

But I haven't thought about this problem since 2013.  I don't sense either, 
from other bug/issues, or Stackoverflow questions, that this is a pressing need.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Steven, do you care to put this to rest?

--
assignee:  -> bethard
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Evan Driscoll]

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* set the flag.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Evan Driscoll]

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, subject to some flag, be of interest?

I can't leave well enough alone, so, with the following additional patch:

-def _match_argument(self, action, arg_strings_pattern):
+def _match_argument(self, action, arg_strings_pattern, arg_strings, 
start_index):
+import numbers
+nargs = action.nargs if action.nargs is not None else 1
+if isinstance(nargs, numbers.Number) and len(arg_strings_pattern) >= 
nargs:
+return nargs
+
 # match the pattern for this action to the arg strings
 nargs_pattern = self._get_nargs_pattern(action)
 match = _re.match(nargs_pattern, arg_strings_pattern)
 ...

Then I get this:

  >>> import argparse
  >>> parser = argparse.ArgumentParser(prog='a2x')
  >>> parser.add_argument('--asciidoc-opts',
  ... action='store', dest='asciidoc_opts', default='',
  ... metavar='ASCIIDOC_OPTS', help='asciidoc options')
  >>> parser.parse_args(['--asciidoc-opts', '--safe'])
  Namespace(asciidoc_opts='--safe')

Comments on this approach?

(Again, I haven't run tests, it'd need to be controlled by a flag per your 
desire to not change existing behavior, etc.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Evan Driscoll]

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

> 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)
> 
> This can be safely added in the current mode with no opt-in required,
> and will relieve the immediate "but what can I do?" confusions of 
> users.  The workaround is hard to discover otherwise, as `--foo=x` is 
> typically equivalent to `--foo x`.

and found it intriguing.

Messing around with the code, I was able to produce the attached patch, which, 
when run on the test case in the original comment, produces this output:

>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument (if you intended 
--safe to be the argument of --asciidoc-opts, pass --asciidoc-opts=--safe 
instead)


Would a cleaned-up version of this patch be of interest? (There are a couple 
obvious problems, like the out-of-bounds access to the list, PEP8, etc.) Is 
there some other way you could suggest to achieve this aim if you don't like 
that approach?

(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, 
subject to some flag, be of interest?)


The patch is relative to, I believe, the distribution version of 2.7.8. (Sorry, 
it's what I had handy as a custom build. :-) Updating it to .14 and to 
3.whatever would be part of the cleanup.)

--
Added file: https://bugs.python.org/file47302/python-argparse-error.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Evan Driscoll]

Change by Evan Driscoll :


--
nosy: +evaned

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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 '--'.  Then optparse continues with the rest.

argparse performs the double pass described earlier, and allocates strings to 
each Action based on the larger context.  It gives as many as the Action's 
nargs requires, but tries in various ways to reserve strings for other Actions. 
 Individual Actions never see the big picture.

So the 'REMAINDER' action has to be last (with this '--' positional exception). 
 Your users will have to use the other flags Actions first.

One alternative comes to mind:

- omit the final positional
- use parse_known_args instead of parse_args

Then the 'extras' list will be something like:  ['--', '--verbose'], which you 
can handle in another parser.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Clint Olsen]

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='*')
p.add_argument('--verbose', action='store_true')

args = p.parse_args('--subscipt_args --foo --bar --baz -- --verbose '.split())

print(args)

usage: test.py [-h] [--subscipt_args ...] [--verbose]
test.py: error: unrecognized arguments: -- --verbose

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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())

produces

Namespace(pos=['other', 'args'], subscipt_args=['--foo', '--bar', '--baz'])

'REMAINDER' is like '*' except it takes everything.  But the '--' means 
'everything that follows is a positional argument, so it effectively ends the 
'REMAINDER'.  'REMAINDER' is documented (briefly), but I don't recall reading 
about its interaction with '--'.  I'm a little surprised that it wasn't 
mentioned earlier in this bug/issue.

'+...', argparse.PARSER is similar except it requires at least one argument.  
It is used by the 'subparsers' argument, to collect the cmd string and use all 
that follow as subparser arguments.

There is a bug issue (or two) about what should happen when there are more than 
one '--' argument.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Clint Olsen]

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:

--subscript_args --foo --bar --baz -- 

So, if you ran args = parser.parse_args()

args.subscript_args = [ '--foo', '--bar', '--baz' ]

Right now I have NO way of enabling this w/o writing my own argument parser, 
and I think it's bizarre that argparse can't do something like this.

And no, I don't want to pass a singly-quoted string to this so I don't have to 
manually split() the arguments which may or may not match what /bin/sh does.

Does this deserve it's own enhancement request?

--
nosy: +Clint Olsen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[SpaceOne]

Changes by SpaceOne :


--
nosy: +spaceone

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Panter]

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 parsing an argument to the option syntax 
independently of what option names are registered?

Also the name “args_default_to_positional=True” name is both unwieldy and vague 
to me. The purpose seems to be to disable option-lookalike-strings from being 
reserved. Maybe call it something like “reserve_all_options=False” or 
“reserve_unregistered_options=False”?

I left some thoughts in the code review for the documentation too.

--
nosy: +martin.panter
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Cherniavsky Beni]

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)

This can be safely added in the current mode with no opt-in required, and will 
relieve the immediate "but what can I do?" confusions of users.  The workaround 
is hard to discover otherwise, as `--foo=x` is typically equivalent to `--foo 
x`.

--- more discussion, though I suspect it's not productive ---

I've tried to find what the GNU Standards or POSIX say about this and was 
surprised to see neither explains how exactly `--opt_with_mandatory_argument 
-quux` behaves.

man getopt says:

 If such a character is followed by a colon, the option requires an 
argument, so getopt() places a pointer to the following text in the same 
argv-element, or the text of the following argv-element, in optarg. Two colons 
mean an option takes an optional arg; if there is text in the current 
argv-element (i.e., in the same word as the option name itself, for example, 
"-oarg"), then it is returned in optarg, otherwise optarg is set to zero. This 
is a GNU extension.

POSIX similarly does explain that an optional arg after an option must follow 
within the same argument:

(2)(b) If the SYNOPSIS shows an optional option-argument (as with [ -f[ 
option_argument]] in the example), a conforming application shall place any 
option-argument for that option directly adjacent to the option in the same 
argument string, without intervening  characters. If the utility 
receives an argument containing only the option, it shall behave as specified 
in its description for an omitted option-argument; it shall not treat the next 
argument (if any) as the option-argument for that option.

-- http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

Anyway, every argument parsing library I've ever seen parses options in a 
left-to-right pass, consuming non-optional arguments after an option whatever 
they look like.  I've never seen a difference between `--foo bar` and 
`--foo=bar` when bar is *non-optional*.

Both behaviors (--opt_with_mandatory_argument bar, 
--opt_with_optional_argument[=bar]) were clearly designed to avoid ambiguity.
Whereas argparse innovated some constructs eg. '--opt', nargs='*' that are 
inherently ambiguous.  But for the simple constructs, most notably nargs=1, 
there should be a way to get the traditional unix meaning.

--
nosy: +cben

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Memeplex]

Memeplex added the comment:

Here is another manifestation of this problem: http://bugs.python.org/issue17050

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Memeplex]

Memeplex added the comment:

What's missing for this patch to be applied? Can I help somehow?

--
nosy: +memeplex

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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
http://bugs.python.org/issue9334
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[paul j3]

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 detecting number-like options like '-1'.  But as used in
_parse_optional() it prevents strings like '-1e4' and '-1-4j' from being
classed as positionals (msg184174).  In this patch it is replaced with

try:
complex(arg_string)
return None
except ValueError:
pass

Immediately before this number test I added

if self.args_default_to_positional:
return None

to implement the idea suggested in msg169978.

I added the args_default_to_positional parser option to the documentation, 
along with some notes on its implications in the `Arguments containing -` 
section.  A few of the examples that I added use scientific or complex numbers.

I tested test_argparse.py with args_default_to_positional=True default.  A 
number of the 'failures' no longer failed.
class TestDefaultToPositionalWithOptionLike illustrates this in the
Option-Like situation.

The only 'successes' to fail were in the TestAddSubparsers case.  There
an argument string  '0.5 -p 1 b -w 7' produced 'wrong choice' error,
since the '-p' was assumed to be a commands choice, rather than an unknown 
optional.

I translated the TestStandard cases from the optparse test file.  argparse ran 
most of these without problem.  The value of args_default_to_positional makes 
no difference.  There a few optparse tests that use '--'  or a valid optional 
as positional that argparse does not handle.

--
keywords: +patch
Added file: http://bugs.python.org/file29548/final.patch

___
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

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

[paul j3]

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 self.args_default_to_positional:
return None

In effect, if the string does not match an action string, say it is a 
positional.

Making this patch to argparse.py is simple. How much to test it, and how 
document it requires more thought.

--

___
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

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

[paul j3]

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 may be overkill.

I'm not as familiar with optparse and other argument processes, but I suspect 
argparse is different in that it processes the argument strings twice.  On one 
loop it parses them, producing an arg_strings_pattern that looks like 'OAA' (or 
'OAO' in these problem cases).  On the second loop is consumes the strings 
(optionals and positionals).  This gives it more power, but produces problems 
like this if the parsing does not match expectations.

--
nosy: +paul.j3

___
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

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

[Evgeny Kapun]

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 matter what it looks like. There should be no 
guesses or heuristics here. That the behavior depends on whether some argument 
looks like a negative number is the most horrible. Argument parsing should 
follow simple, deterministic rules, preferably the same that used by standard 
getopt(3).

--

___
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

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

[Eric V. Smith]

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 backward compatibility concerns. The discussion in this issue 
describes those compatibility concerns.

--

___
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

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

[paul j3]

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 
(_optionals, _positionals) or any subparsers. The code takes special care to 
make sure that the related property: _has_negative_number_optionals is properly 
shared among all these ActionContainers.

--

___
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

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

[paul j3]

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 determine whether an option_string is a 
'negative number', and hence whether to modify the _hasNegativeNumberOptionals 
flag.  If this matcher is the general r'^-.+$', adding the default '-h' will 
set this flag.  We don't want that.

Using a different matcher for these two containers might work, but is awfully 
kludgy.

--

___
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

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

[Evgeny Kapun]

Changes by Evgeny Kapun abacabadabac...@gmail.com:


--
nosy: +abacabadabacaba

___
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

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

[Daniel Shahaf]

Changes by Daniel Shahaf pyt...@danielsh.fastmail.net:


--
nosy: +danielsh

___
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

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

[Tim Cuthbertson]

Changes by Tim Cuthbertson tim3d.j...@gmail.com:


--
nosy: +gfxmonk

___
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

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

[Steven Bethard]

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 that args default to optional arguments if they 
look like optionals).

I'd be happy to review a patch along these lines. It would probably be good if 
Anders Kaseorg could also review it to make sure it fully solves his problem.

--

___
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

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

[Christophe Guillon]

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 = re.compile(r'^-.+$')

This allow cases such as @andersk:
$ a2x --asciidoc-opts --safe gitcli.txt
where '--safe' is an argument to '--asciidoc-opts'

As this behavioral change is quite simple, couldn't the requested feature be 
implemented like this with an optional setting to the ArgumentParser contructor?

--
nosy: +Christophe.Guillon

___
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

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

[Andrew McNabb]

Changes by Andrew McNabb amcn...@mcnabbs.org:


--
nosy: +amcnabb

___
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

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

[James B]

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 as that is expected in 
general to result in strings to be correctly handled (these args are API keys, 
so they could contain shell-unfriendly chars like - and ).

./tool.py  arg1 'arg2' '-arg3otherstuff' 

You'll note there are no optional arguments in this example, it just boils down 
to a positional argument being broken up on parse.

Needless to say it was quite confusing to see the script complain after passing 
in what would typically be perfectly valid strings in most other apps / scripts.

Is it possible to get argparse to correctly notice and handle shell-appropriate 
single-quoting methods(dont break down a string that has been implied as a 
complete token via ' ')

As it stands, it appears I have two workaround options: 1) adopt the ./tool.py 
-- postional args convention mentioned in this thread, or 2) escape leading 
dashes in positional argument strings to avoid this issue.

--
nosy: +skilletaudio

___
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

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

[Anders Kaseorg]

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.

Your observation isn’t a bug.  In all getopt-like parsers, -- is the only way 
to pass positional arguments beginning with -.  (Whether you shell-quoted the 
argument is irrelevant; the - is interpreted by the program, not the shell, 
after the shell has already stripped off the shell quoting.)

If your program doesn’t take any options and you’d like to parse positional 
arguments without requiring --, don’t use a getopt-like parser; use sys.argv 
directly.

If you still think your example is a bug, please file a separate report.

--

___
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

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

[Steven Bethard]

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 fixed number of 
arguments be acceptable for your use case?

--
versions:  -Python 3.1

___
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

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

[Anders Kaseorg]

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 getopt_long() supports options with an optional argument 
under the restrictions that:
 • the option must be a long option,
 • the optional argument must be the only argument for the option, and
 • the argument, if present, must be supplied using the
   ‘--option=argument’ form, not the ‘--option argument’ form.
This avoids all parsing ambiguity.  It would be useful to have feature parity 
with getopt_long(), to facilitate writing Python wrapper scripts for C programs.

--

___
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

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

[Eric Smith]

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 arparse's 
existing behavior with respect to optional arguments.

For example:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs='?')
parser.add_argument('--bar', nargs='?')
print parser.parse_args(['--foo', '--bar', 'a'])
print parser.parse_args(['--foo', 'x', '--bar', 'a'])

Unless the parser tries to guess that --bar is an optional argument by itself, 
it can't know that --foo has an argument or not.

I guess it could look and say that if you called this with '--foo --baz', then 
'--baz' must be an argument for '--foo', but then you could never have an 
argument to '--foo' named '--bar', plus it all seems fragile.

Maybe this new parser (as Steven described it) wouldn't allow a variable number 
of arguments to optional arguments? That is, nargs couldn't be '?', '*', or 
'+', only a number.

--

___
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

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

[Steven Bethard]

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 parser.

--

___
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

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

[Eric Smith]

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 ends up being called) is True.

--

___
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

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

[Eric Smith]

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.

--

___
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

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

[Steven Bethard]

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, the time honored workaround is 
to prefix with ./

$ cd ./-links-/
$

Anyway, it doesn't seem like anyone is offering to write up a patch to enable 
such an alternative parsing strategy, perhaps Eric's = workaround should be 
documented prominently somewhere?

--

___
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

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

[Éric Araujo]

É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

___
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

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

[Eric Smith]

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: invalid option
cd: usage: cd [-L|-P] [dir]
$ cd -- -links-
$

This would also work with argparse:
import argparse
parser = argparse.ArgumentParser(prog='cd')
parser.add_argument('-L', help='follow symbolic links')
parser.add_argument('-P', help='do not follow symbolic links')
parser.add_argument('dir', help='directory name')
print(parser.parse_args(['--', '-Links-']))

prints:
Namespace(L=None, P=None, dir='-Links-')

Continuing the example from my earlier post shows it won't work for values for 
optional arguments:
 parser.parse_args(['--asciidoc-opts -- -one'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: unrecognized arguments: --asciidoc-opts -- -one

I believe it's only the '=' that will solve this problem. In fact, because of 
this issue, I suggest we document '=' as the preferred way to call argparse 
when optional arguments have values, and change all of the examples to use it. 
I also think it would cause less confusion (because of this issue) if the help 
output showed the equal sign. But I realize that's probably more controversial.

--

___
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

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

[Anders Kaseorg]

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 0x7fc97a93a7e8: {'a': ('-first', '-second')}, [])

But inputting those arguments is _not possible_ with argparse.

 parser = argparse.ArgumentParser()
 parser.add_argument('-a', nargs=2)
 parser.parse_args(['-a', '-first', '-second'])
usage: [-h] [-a A A]
: error: argument -a: expected 2 argument(s)

--

___
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

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

[Eric Smith]

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 solution.

We can change the documentation to point out the issue now, but the feature 
request can only go in 3.3.

--

___
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

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

[Anders Kaseorg]

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 documentation for older versions, would it be reasonable to 
un-deprecate optparse until argparse becomes a suitable replacement?  There are 
still lots of programmers working in Python 2.7.

[1] bethard’s msg128047 is confusing positional arguments with option 
arguments.  All UNIX commands that accept option arguments have no trouble 
accepting option arguments that begin with -.  For example, ‘grep -e -pattern 
file’ is commonly used to search for patterns beginning with -.

--

___
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

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

[Eric Smith]

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 released behavior in the stdlib is problematic, as everyone knows.

I'll look into producing a patch to add this as optional behavior, then we can 
separately think about changing the default.

--

___
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

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

[Steven Bethard]

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 from Python.

(2) One (mis?)feature doesn't make the rest of the module useless.

And yes Eric, it would be awesome if you could develop a patch that allows the 
alternate parsing to be enabled when someone wants it. We should think about 
deprecation strategy though. Maybe something like:

== Python 3.3 ==
# Python 3.2 behavior
parser = ArgumentParser(error_on_unknown_options=True)
# proposed behavior
parser = ArgumentParser(error_on_unknown_options=False)
# deprecation warning when not specified
parser = ArgumentParser()

== Python 2.4 ==
# error warning when not specified
parser = ArgumentParser()

== Python 2.5 ==
# defaults to error_on_unknown_options=False
parser = ArgumentParser()

I'm not sure that's the right way to do it, but if the plan is to change the 
default at some point, we should make sure that we have a deprecation plan 
before we add the feature.

--

___
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

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

[Éric Araujo]

É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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Benjamin]

Changes by David Benjamin david...@mit.edu:


--
nosy: +davidben

___
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

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

[Anders Kaseorg]

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 = ArgumentParser(error_on_unknown_options=False)

Perhaps you weren’t literally proposing “error_on_unknown_options=False” as the 
name of the new flag, but note that neither the current nor proposed behaviors 
have nothing to do with whether arguments look like known or unknown options.  
Under the proposed behavior, anything in argument position (--asciidoc-opts 
___) is parsed as an argument, no matter what it looks like.

So a more accurate name might be “refuse_dashed_args=False”, or more generally 
(in case prefix_chars != '-'), “refuse_prefixed_args=False”?

--

___
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

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

[Steven Bethard]

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 everything that looks like 
a flag is intended to be one, before it ever looks at how many arguments the 
flag before it takes or anything like that. This is the source of your problem 
- argparse assumes -safe is a flag, and as a result, there is no argument for 
--asciidoc-opts'. So perhaps a better name would be something like 
dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one. ;-)

--

___
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

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

[Gerard van Helden]

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 by 
the parser library.

--
nosy: +drm

___
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

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

[Eric Smith]

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', dest='asciidoc_opts', default=''
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
 parser.parse_args(['--asciidoc-opts', '-1'])
Namespace(asciidoc_opts='-1')
 parser.parse_args(['--asciidoc-opts=-one'])
Namespace(asciidoc_opts='-one')

I always use the equal sign, so I've never noticed this behavior before.

I wish that help would display the equal sign, but that's another issue.

--
versions: +Python 3.3 -Python 3.2

___
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

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

[Steven Bethard]

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 
proposal, the --foo option will now silently consume the --bar option 
without an error. I know this is good from your perspective, but it would 
definitely break some of my scripts, and I imagine it would break other 
people's scripts as well.

As I keep saying, I'm happy to add your alternative parsing as an option 
(assuming you provide a patch), but I really don't think it's the right thing 
to do by default. Most command line programs don't have options that take other 
option-like things as arguments (which is the source of your problem), so in 
most command line programs, people want an error when they get an option they 
don't recognize or an option that's missing its argument. Under your proposal, 
more such errors will pass silently and will have to be caught by additional 
code in the script.

--

___
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

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

[Steven Bethard]

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 doesn't support it, or the --bar was meant to be the argument to 
the --foo flag. At this point, the parser must make an arbitrary decision, 
and argparse chooses the interpretation that the user wanted the --bar flag.

I understand that you have a good use case for the other interpretation. That's 
why I suggest you come up with a patch that allows this other interpretation to 
be enabled when necessary. 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).

--

___
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

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

[Anders Kaseorg]

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

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

[Anders Kaseorg]

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 ‘--’ can’t begin with a 
dash (I don’t think there’s any confusion over how those should work).
  arguments = *(non-dash-positional-argument / option) [-- 
*(positional-argument)]
  non-dash-positional-argument = string not beginning with -
  positional-argument = string

The point was just that the grammar unambiguously allows the argument of --foo 
to be any string.

--

___
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

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

[Steven Bethard]

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 information:

http://docs.python.org/library/argparse.html#arguments-containing

Your problem is that you want --safe to be treated as a positional argument 
even though you've declared it as an option. Basically there are two reasonable 
interpretations of this situation. Consider something like --conf-file 
--safe. Either the user wants a conf file named --safe, or the user 
accidentally forgot to type the name of the conf file. Argparse assumes the 
latter, though either one is conceivable. Argparse assumes the latter because, 
while it occasionally throws an unnecessary exception, the other behavior would 
allow an error to pass silently.

I'm definitely opposed to changing the default behavior to swallow some errors 
silently. If you'd like to propose an API for enabling such behavior explicitly 
and supply a patch and tests implementing it, I'll be happy to review it though.

--

___
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

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

[Anders Kaseorg]

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',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
 parser.parse_args(['--asciidoc-opts', '-1'])
Namespace(asciidoc_opts='-1')
 parser.parse_args(['--asciidoc-opts', '-one'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument

 Your problem is that you want --safe to be treated as a positional
 argument even though you've declared it as an option.

No, it doesn’t matter whether --safe was declared as an option: argparse 
rejected it on the basis of beginning with a dash (as I demonstrated in my 
small test case, which did not declare --safe as an option, and again in the 
example above with -one).

 Either the user wants a conf file named --safe, or the user
 accidentally forgot to type the name of the conf file.

But it’s not argparse’s job to decide that the valid option I passed was 
actually a typo for something invalid.  This would be like Python rejecting the 
valid call
  shell = bash
  p = subprocess.Popen(shell)
just because shell happens to also be a valid keyword argument for the Popen 
constructor and I might have forgotten to specify its value.

Including these special heuristics by default, that (1) are different from the 
standard behavior of all other option parsing libraries and (2) interfere with 
the ability to pass certain valid options, only leads to strange 
inconsistencies between command line programs written in different languages, 
and ultimately makes the command line harder to use for everyone.  The default 
behavior should be the standard one.

--

___
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

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

[Anders Kaseorg]

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 ATTRIBUTE] [--asciidoc-opts ASCIIDOC_OPTS]
   [--copy] [--conf-file CONF_FILE] [-D PATH] [-d DOCTYPE]
   [--epubcheck] [-f FORMAT] [--icons] [--icons-dir PATH] [-k]
   [--lynx] [-L] [-n] [-r PATH] [-s] [--stylesheet STYLESHEET]
   [--safe] [--dblatex-opts DBLATEX_OPTS] [--fop]
   [--fop-opts FOP_OPTS] [--xsltproc-opts XSLTPROC_OPTS] [-v]
a2x: error: argument --asciidoc-opts: expected one argument

Apparently argparse uses a heuristic to try to guess whether an argument looks 
like an argument or an option, going so far as to check whether it looks like a 
negative number (!).  It should _never_ guess: the option was specified to take 
an argument, so the following argument should always be parsed as an argument.

Small test case:

 import optparse
 parser = optparse.OptionParser(prog='a2x')
 parser.add_option('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
 parser.parse_args(['--asciidoc-opts', '--safe'])
(Values at 0x7f585142ef80: {'asciidoc_opts': '--safe'}, [])

 import argparse
 parser = argparse.ArgumentParser(prog='a2x')
 parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
 parser.parse_args(['--asciidoc-opts', '--safe'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument

--
components: Library (Lib)
messages: 111221
nosy: andersk
priority: normal
severity: normal
status: open
title: argparse does not accept options taking arguments beginning with dash 
(regression from optparse)
versions: Python 2.7, Python 3.2, Python 3.3

___
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

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

[Eric Smith]

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 list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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.  Since argparse has been released, I'm thinking this still has to be a 
feature request, since argparse is *not* a drop-in replacement for optparse.

--
nosy: +bethard, r.david.murray
stage:  - unit test needed
type:  - feature request
versions:  -Python 2.7, Python 3.3

___
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

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

[Nelson Elhage]

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, in favor of an arbitrary heuristic that sometimes guesses wrong. 
That's not the kind of behavior I expect from my Python libraries; I want them 
to do what I ask them to, not try to guess what I probably meant.

--
nosy: +nelhage

___
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

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

[Anders Kaseorg]

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 passed in?  Shouldn’t that be up to the caller (or up to 
the program, if it explicitly decides to reject such arguments)?

Keep in mind that the caller might be another script instead of a user.

--

___
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

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

[Greg Brockman]

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
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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
http://bugs.python.org/issue9334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com