This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author karzes
Recipients Christophe.Guillon, Clint Olsen, Socob, abacabadabacaba, amcnabb, andersk, bethard, cben, danielsh, davidben, drm, eric.araujo, eric.smith, evaned, fennec15, gaborjbernat, gdb, gfxmonk, karzes, maggyero, martin.panter, memeplex, nelhage, orivej, paul.j3, porton, r.david.murray, rhettinger, skilletaudio, spaceone, xtreak
Date 2021-10-18.21:59:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2021-10-18 21:59:48karzessetrecipients: + karzes, rhettinger, cben, amcnabb, bethard, eric.smith, orivej, eric.araujo, r.david.murray, memeplex, gfxmonk, evaned, andersk, abacabadabacaba, gdb, nelhage, drm, davidben, martin.panter, paul.j3, skilletaudio, Christophe.Guillon, danielsh, spaceone, Clint Olsen, porton, Socob, maggyero, xtreak, fennec15, gaborjbernat
2021-10-18 21:59:48karzessetmessageid: <>
2021-10-18 21:59:48karzeslinkissue9334 messages
2021-10-18 21:59:48karzescreate