getopt.getopt error processing long_options

[hagertmbbcedu]

BPO	28171
Nosy	@stevendaprano

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-09-15.19:04:24.158>
created_at = <Date 2016-09-15.18:56:36.528>
labels = ['type-bug', 'invalid']
title = 'getopt.getopt error processing long_options'
updated_at = <Date 2016-09-15.19:44:38.311>
user = 'https://bugs.python.org/hagertmbbcedu'

bugs.python.org fields:

activity = <Date 2016-09-15.19:44:38.311>
actor = 'steven.daprano'
assignee = 'none'
closed = True
closed_date = <Date 2016-09-15.19:04:24.158>
closer = 'SilentGhost'
components = []
creation = <Date 2016-09-15.18:56:36.528>
creator = 'hagertmb@bc.edu'
dependencies = []
files = []
hgrepos = []
issue_num = 28171
keywords = []
message_count = 8.0
messages = ['276588', '276591', '276594', '276595', '276597', '276602', '276603', '276607']
nosy_count = 3.0
nosy_names = ['steven.daprano', 'SilentGhost', 'hagertmb@bc.edu']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue28171'
versions = ['Python 2.7']

[hagertmbbcedu]

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 (?)

[SilentGhost]

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"

[hagertmbbcedu]

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\>

---

[SilentGhost]

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.

[stevendaprano]

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

[stevendaprano]

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.

[hagertmbbcedu]

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\>

---

[stevendaprano]

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.