Tom Karzes <[email protected]> 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 <[email protected]>
<https://bugs.python.org/issue9334>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
