Tom Karzes <kar...@sonic.net> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue9334> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
