The exceptions thrown by the socket module could be
better thought out.

1/ Inconsistent Parameters For socket error:
The python documentation for socket.error says "The
accompanying value is either a string telling what went
wrong or a pair (errno, string) representing an error
returned by a system call". I assume this is because an
errno is not always available in an error situation.

However, this inconsistency is annoying. If I want to
catch a socket error and (try to) do some
error-number-specific handling, I need to do something
like this:

try:
  someNetworkingFunc()
except socket.error, ex:
  if len(ex.args) == 2 and type(ex.args[0]) == IntType:
    errorNumber = ex.args[0]
    errorMsg = ex.args[1]
    handleSocketErrorByNumber(errorNumber, errorMsg)
  else:
    handleUnknownSocketError(ex)

Some different ways to resolve this:
  (a) Force socket.error to always have args of (errno,
message). We use a special errno value when none is
actually available.
  (b) Subclass socket.error to have one version with
errno and message, and one version with only a message


2/ Better Class Hierarchy:
It would be easier to handle the various socket errors
if we had more of a class hierarchy. eg.
EnvironmentError
  -> socket.error
    -> socket.timeout
  -> socket.AddressError
    -> socket.herror
    -> socket.gaierror

3/ Use Named Attributes:
It would be easier to access the parameters in
exceptions if we made them named attributes. eg.

class socket.error(EnvironmentError):
  def __init__(self, errno, msg):
    self.errno = errno
    self.msg = msg
    
    # Also pass on the params to the parent class,
    # to ensure compatibility with existing code
    # that accesses the params via ex.args
    EnvironmentError.__init__(self, errno, msg)


try:
  someNetworkingFunc()
except socket.error, ex:
  print "Error number is %d" % ex.errno