Skip to content

Commit d31b632

Browse files
committed
getopt used to sort the long option names, in an attempt to simplify
the logic. That resulted in a bug. My previous getopt checkin repaired the bug but left the sorting. The solution is significantly simpler if we don't bother sorting at all, so this checkin gets rid of the sort and the code that relied on it.
1 parent 36cdad1 commit d31b632

File tree

1 file changed

+2
-12
lines changed

1 file changed

+2
-12
lines changed

Lib/getopt.py

Lines changed: 2 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,6 @@ def getopt(args, shortopts, longopts = []):
6565
longopts = [longopts]
6666
else:
6767
longopts = list(longopts)
68-
longopts.sort()
6968
while args and args[0].startswith('-') and args[0] != '-':
7069
if args[0] == '--':
7170
args = args[1:]
@@ -99,19 +98,10 @@ def do_longs(opts, opt, longopts, args):
9998
# Return:
10099
# has_arg?
101100
# full option name
102-
# Assumes longopts has been sorted (ASCII order).
103101
def long_has_args(opt, longopts):
104-
for i in range(len(longopts)):
105-
if longopts[i].startswith(opt):
106-
break
107-
else:
102+
possibilities = [o for o in longopts if o.startswith(opt)]
103+
if not possibilities:
108104
raise GetoptError('option --%s not recognized' % opt, opt)
109-
# opt is a prefix of longopts[i]; find j s.t. opt is a prefix of
110-
# each possibility in longopts[i:j]
111-
j = i+1
112-
while j < len(longopts) and longopts[j].startswith(opt):
113-
j += 1
114-
possibilities = longopts[i:j]
115105
# Is there an exact match?
116106
if opt in possibilities:
117107
return 0, opt

0 commit comments

Comments
 (0)