Author eric.smith
Recipients Christophe.Guillon, Clint Olsen, abacabadabacaba, amcnabb, andersk, bethard, cben, danielsh, davidben, drm, eric.araujo, eric.smith, evaned, gdb, gfxmonk, karzes, martin.panter, memeplex, nelhage, paul.j3, r.david.murray, rhettinger, skilletaudio, spaceone
Date 2018-01-09.09:08:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1515488893.39.0.467229070634.issue9334@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2018-01-09 09:08:13eric.smithsetrecipients: + eric.smith, rhettinger, cben, amcnabb, bethard, 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, karzes
2018-01-09 09:08:13eric.smithsetmessageid: <1515488893.39.0.467229070634.issue9334@psf.upfronthosting.co.za>
2018-01-09 09:08:13eric.smithlinkissue9334 messages
2018-01-09 09:08:13eric.smithcreate