Tom Karzes <kar...@sonic.net> 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 <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
