Issue 6977: Getopt documentation ambiguity (original) (raw)

Created on 2009-09-23 12:08 by SilentGhost, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg93033 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2009-09-23 12:08
the following >>> getopt.getopt('--testing=dr'.split(), '', ['testing'])[0] would raise 'option --testing must not have an argument'. Documentation reads, however: "Long options which require an argument should be followed by an equal sign ('=')." Which is equivalent to "options that don't require an argument, should not be followed by the equal sign". The fact that in my example argument is not required does not mean that argument cannot be passed.
msg93035 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-09-23 13:59
Sorry, I don't understand what the issue is. Long options with arguments use 'testing=', those without use 'testing'. Could you please elaborate?
msg93038 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2009-09-23 14:30
issue is in the wording: "Long options which require an argument should be followed by an equal sign ('=')." What if the argument is optional? Then by definition it is not required, but as my example shows omitting the equal sign, would produce the error. I'd suggest that the docs should read something along these lines: "Long options which accept an argument should be followed by an equal sign ('='). Passing an argument to an option without an equal sign is illegal." Basically, it's not clear that "optional" arguments should be passed like this: >>> getopt.getopt('--testing='.split(), '', ['testing']) Note the difference with my previous example.
msg93039 - (view) Author: Doug Hellmann (doughellmann) * (Python committer) Date: 2009-09-23 14:36
Is there a way in getopt to define an option that takes an optional argument? I thought options either required args or did not accept them at all.
msg93040 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2009-09-23 14:39
Yes, that's true Doug. May be it should be explicitly stated?
msg94359 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-10-22 15:54
Fixed in r75613.
History
Date User Action Args
2022-04-11 14:56:53 admin set github: 51226
2009-10-22 15:54:43 georg.brandl set status: open -> closedresolution: fixedmessages: +
2009-09-23 14:39:35 SilentGhost set messages: +
2009-09-23 14:36:25 doughellmann set nosy: + doughellmannmessages: +
2009-09-23 14:30:41 SilentGhost set messages: +
2009-09-23 13:59:06 georg.brandl set messages: +
2009-09-23 12:08:12 SilentGhost create