Issue 28171: getopt.getopt error processing long_options (original) (raw)
Created on 2016-09-15 18:56 by hagertmb@bc.edu, last changed 2022-04-11 14:58 by admin. This issue is now closed.
Messages (8)
Author: Mike Hagerty (hagertmb@bc.edu)
Date: 2016-09-15 18:56
Here's the relevant code:
opts, args = getopt.getopt(sys.argv[1:], "ih", ["help", "f1Hz","startdate=", "ndays="])
main.py -i --f1H --startdat=2016-08-22 --ndays 2
Here's what getopt returns into opts: opts= [('-i', ''), ('--f1Hz', ''), ('--startdate', '2016-08-22'), ('--ndays', '2')]
As you can see, I gave incomplete long_option names ("--f1H" instead of "--f1Hz", "startdat" instead of "startdate") but getopt doesn't care.
getopt appears to scan just until the end of the input flag ("--f1H") and replaces this in opts with the full flag name passed to it ("--f1Hz") that matches the first characters.
This means, for instance, you couldn't do:
main.py --flag1=something --flag11=something_else
Surely this isn't intended behavior (?)
Author: SilentGhost (SilentGhost) * 
Date: 2016-09-15 19:04
It's a documented behaviour: "Long options on the command line can be recognized so long as they provide a prefix of the option name that matches exactly one of the accepted options"
Author: Mike Hagerty (hagertmb@bc.edu)
Date: 2016-09-15 19:08
Huh ?
"documented behaviour" ?
How is silently failing to resolve input errors okay ?
On Thu, Sep 15, 2016 at 3:04 PM, SilentGhost <report@bugs.python.org> wrote:
SilentGhost added the comment:
It's a documented behaviour: "Long options on the command line can be recognized so long as they provide a prefix of the option name that matches exactly one of the accepted options"
nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed
Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28171>
Author: SilentGhost (SilentGhost) *
Date: 2016-09-15 19:10
It's not an error. Read the docs, there's a longer and more detailed explanation there. There is no chance of this being changed, not in a module like getopt.
Author: Steven D'Aprano (steven.daprano) * 
Date: 2016-09-15 19:16
Surely this isn't intended behavior (?)
It is indeed. That's standard behaviour for GNU getopt, which the Python module is modelled after:
[steve@ando ~]$ getopt --version getopt (enhanced) 1.1.4 [steve@ando ~]$ getopt --versi getopt (enhanced) 1.1.4
Author: Steven D'Aprano (steven.daprano) *
Date: 2016-09-15 19:20
How is silently failing to resolve input errors okay ?
You haven't demonstrated that it fails to resolve input errors. You have demonstrated a feature, not a bug: getopt will accept prefixes if they unambiguously match ONE long option only. If the prefix matches two or more options, then the prefix is ambiguous and getopt will not accept it.
Author: Mike Hagerty (hagertmb@bc.edu)
Date: 2016-09-15 19:26
You win. It's not a bug, it's a feature ... that renders the module incorrect by any reasonable definition.
argparse here I come!
On Thu, Sep 15, 2016 at 3:20 PM, Steven D'Aprano <report@bugs.python.org> wrote:
Steven D'Aprano added the comment:
How is silently failing to resolve input errors okay ?
You haven't demonstrated that it fails to resolve input errors. You have demonstrated a feature, not a bug: getopt will accept prefixes if they unambiguously match ONE long option only. If the prefix matches two or more options, then the prefix is ambiguous and getopt will not accept it.
Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28171>
Author: Steven D'Aprano (steven.daprano) *
Date: 2016-09-15 19:44
argparse here I come!
https://docs.python.org/2/library/argparse.html#argument-abbreviations-prefix-matching
Prefix matching is a standard feature of all command line option parsers that I know of.
History
Date
User
Action
Args
2022-04-11 14:58:36
admin
set
github: 72358
2016-09-15 19:44:38
steven.daprano
set
messages: +
2016-09-15 19:26:04
set
messages: +
2016-09-15 19:20:38
steven.daprano
set
messages: +
2016-09-15 19:16:17
steven.daprano
set
nosy: + steven.daprano
messages: +
2016-09-15 19:10:04
SilentGhost
set
messages: +
2016-09-15 19:08:17
set
messages: +
2016-09-15 19:04:24
SilentGhost
set
status: open -> closed
nosy: + SilentGhost
messages: +
resolution: not a bug
stage: resolved
2016-09-15 18:56:36
create