[issue28171] getopt.getopt error processing long_options

Steven D'Aprano added the comment: > 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. -- ___ Python

[issue28171] getopt.getopt error processing long_options

Mike Hagerty added the comment: 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 wrote: > > Steven D'Aprano added the comment: > > > How is silently failing to re

[issue28171] getopt.getopt error processing long_options

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

[issue28171] getopt.getopt error processing long_options

Steven D'Aprano added the comment: > 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 -

[issue28171] getopt.getopt error processing long_options

SilentGhost added the comment: 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. -- ___ Python tracker

[issue28171] getopt.getopt error processing long_options

Mike Hagerty added the comment: Huh ? "documented behaviour" ? How is silently failing to resolve input errors okay ? On Thu, Sep 15, 2016 at 3:04 PM, SilentGhost wrote: > > SilentGhost added the comment: > > It's a documented behaviour: "Long options on the command line can be > recognized

[issue28171] getopt.getopt error processing long_options

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 stat

[issue28171] getopt.getopt error processing long_options

New submission from Mike Hagerty: 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-