Python 3.4.3 (default, Nov 17 2016, 01:08:31) 
[GCC 4.8.4] on linux
>>> from getopt import getopt
>>> argv = [ '-a', '-b', '-c', '-d', 'foo']
>>> opts, args = getopt( argv, 'abc:d:')
>>> opts
[('-a', ''), ('-b', ''), ('-c', '-d')]
>>> args
['foo']

Expected behavior:
opts = [('-a', ''), ('-b', ''), ('-c', ''), ('-d', 'foo')]
Throws execption:
getopt.GetoptError: option -c requires argument

Note that -c requires a value, getopt swallows the next option '-d' as the argument to -c.  However, if -c is the last option on the command line getopt properly throws an execption "getopt.GetoptError: option -c requires argument".

The documentation states that getopt will throw an exception when an option requiring a value is missing and exception will be thrown.
"exception getopt.GetoptError
This is raised when an unrecognized option is found in the argument list or when an option requiring an argument is given none."

The option -c requires an argument, none was given, no exception is thrown.  Instead the next option, '-d', is taken as the argument.  I have also tried this test on 2.7 with the same result.

It's not clear what you expected the behaviour to be. A function cannot both raise an exception and return a value.

In any case, you are correct in saying "the next option, '-d', is taken as the argument." I do not think this is a bug. See <http://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html> for the Posix specification of "getopt".

Perhaps you are confused by a bug or quirk of "argparse", where it treats most CLI arguments that begin with a dash specially, even if according to Posix they would be associated with an option. See Issue 9334.

I concur with Martin. This is not a bug.