Getopt documentation ambiguity

[SilentGhost]

BPO	6977
Nosy	@birkenfeld, @dhellmann

^{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 = 'https://github.com/birkenfeld'
closed_at = <Date 2009-10-22.15:54:43.923>
created_at = <Date 2009-09-23.12:08:11.960>
labels = ['library', 'docs']
title = 'Getopt documentation ambiguity'
updated_at = <Date 2009-10-22.15:54:43.921>
user = 'https://bugs.python.org/SilentGhost'

bugs.python.org fields:

activity = <Date 2009-10-22.15:54:43.921>
actor = 'georg.brandl'
assignee = 'georg.brandl'
closed = True
closed_date = <Date 2009-10-22.15:54:43.923>
closer = 'georg.brandl'
components = ['Documentation', 'Library (Lib)']
creation = <Date 2009-09-23.12:08:11.960>
creator = 'SilentGhost'
dependencies = []
files = []
hgrepos = []
issue_num = 6977
keywords = []
message_count = 6.0
messages = ['93033', '93035', '93038', '93039', '93040', '94359']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'doughellmann', 'SilentGhost']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue6977'
versions = ['Python 2.6', 'Python 3.1']

[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 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.

[birkenfeld]

Sorry, I don't understand what the issue is. Long options with
arguments use 'testing=', those without use 'testing'. Could you please
elaborate?

[SilentGhost]

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.

[dhellmann]

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.

[SilentGhost]

Yes, that's true Doug. May be it should be explicitly stated?

[birkenfeld]

Fixed in r75613.