[issue6977] Getopt documentation ambiguity

Georg Brandl added the comment: Fixed in r75613. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bug

[issue6977] Getopt documentation ambiguity

SilentGhost added the comment: Yes, that's true Doug. May be it should be explicitly stated? -- ___ Python tracker ___ ___ Python-bugs

[issue6977] Getopt documentation ambiguity

Doug Hellmann added the comment: 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. -- nosy: +doughellmann ___ Python tracker

[issue6977] Getopt documentation ambiguity

SilentGhost added the comment: 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 sug

[issue6977] Getopt documentation ambiguity

Georg Brandl added the comment: Sorry, I don't understand what the issue is. Long options with arguments use 'testing=', those without use 'testing'. Could you please elaborate? -- ___ Python tracker

[issue6977] Getopt documentation ambiguity

New submission from SilentGhost : 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 equi