• except Exception: vs except BaseException::

  The difference between catching Exception and BaseException is that according to the exception hierarchy exception like SystemExit, KeyboardInterrupt and GeneratorExit will not be caught when using except Exception because they inherit directly from BaseException.

• except: vs except BaseException::

  The difference between this two is mainly in python 2 (AFAIK), and it's only when using an old style class as an Exception to be raised, in this case only expression-less except clause will be able to catch the exception eg.

  class NewStyleException(Exception): pass
  
  try:
     raise NewStyleException
  except BaseException:
     print "Caught"
  
  class OldStyleException: pass
  
  try:
     raise OldStyleException
  except BaseException:
     print "BaseException caught when raising OldStyleException"
  except:
     print "Caught"
  

The accepted answer is incorrect incomplete (at least for Python 3.6 and above).

By catching Exception you catch most errors - basically all the errors that any module you use might throw.

By catching BaseException, in addition to all the above exceptions, you also catch exceptions of the types SystemExit, KeyboardInterrupt, and GeneratorExit.

By catching KeyboardInterrupt, for example, you may stop your code from exiting after an initiated exit by the user (like pressing ^C in the console, or stopping launched application on some interpreters). This could be a wanted behavior (for example - to log an exit), but should be used with extreme care!

In the above example, by catching BaseException, you may cause your application to hang when you want it to exit.

By default, all user-defined exceptions should inherit from Exception. This is recommended in the documentation:

exception Exception

All built-in, non-system-exiting exceptions are derived from this class. All user-defined exceptions should also be derived from this class.

This is also recommend by and motivated in PEP 8:

Derive exceptions from Exception rather than BaseException. Direct inheritance from BaseException is reserved for exceptions where catching them is almost always the wrong thing to do.

In general, exceptions deriving from Exception are intended to be handled by regular code. In contrast, exceptions deriving directly from BaseException are associated with special situations; handling them like normal exceptions can lead to unexpected behaviour. This is why an idiomatic "catch all" handler only handles Exception:

def retry(func):
    while True:
        try:
            return func()
        except Exception as err:
            print(f"retrying after {type(err)}: {err}")

Builtin exceptions inheriting directly from BaseException currently are KeyboardInterrupt, SystemExit, and GeneratorExit which are associated with shutdown of the program, thread or generator/coroutine. Incorrectly handling them will prevent a graceful shutdown.

Note that while the default should be to inherit from Exception, it is fine to inherit from BaseException if there is a good reason to do so. For example, asyncio.CancelledError also inherits from BaseException since it represents shutdown of asyncio's thread equivalent, the Task.

Exceptions derived from BaseException are: GeneratorExit, KeyboardInterrupt, SystemExit.

According to the documentation:

• GeneratorExit: Raised when a generator‘s close() method is called. It directly inherits from BaseException instead of StandardError since it is technically not an error.
• KeyboardInterrupt: Raised when the user hits the interrupt key (normally Control-C or Delete). During execution, a check for interrupts is made regularly. Interrupts typed when a built-in function input() or raw_input() is waiting for input also raise this exception. The exception inherits from BaseException so as to not be accidentally caught by code that catches Exception and thus prevent the interpreter from exiting.
• SystemExit: The exception inherits from BaseException instead of StandardError or Exception so that it is not accidentally caught by code that catches Exception. This allows the exception to properly propagate up and cause the interpreter to exit.

So the usual reasons are to prevent try ... except Exception accidently prevent interpreter exit (except GeneratorExit)

UPDATE after seeing Ashwini Chaudhary's comment:

PEP 352 - Required Superclass for Exceptions explains the reason.

With the exception hierarchy now even more important since it has a basic root, a change to the existing hierarchy is called for. As it stands now, if one wants to catch all exceptions that signal an error and do not mean the interpreter should be allowed to exit, you must specify all but two exceptions specifically in an except clause or catch the two exceptions separately and then re-raise them and have all other exceptions fall through to a bare except clause:

except (KeyboardInterrupt, SystemExit):
    raise
except:
    ...

That is needlessly explicit. This PEP proposes moving KeyboardInterrupt and SystemExit to inherit directly from BaseException.