try: finally: question

[Joshua Marshall]

Tim Peters <tim.peters at gmail.com> wrote:
...
> Ancient Python also had a clearly defined order, but that doesn't
> matter:  the point was that, in practice, people couldn't remember the
> details, and routinely wrote broken code as a result.  There's nothing
> especially compelling about either way of resolving the question (note
> that an enthusiastic "but it's obvious that an exception raised during
> an 'except' clause should not enter the 'finally' block!" was one old
> response in this thread), and Python doesn't allow int+string for
> exactly the same reason.  Not because it can't be defined clearly, but
> because any way of defining it is so arbitrary it leaves half of
> programmers believing that the other way of defining it was "the only
> obvious" way.  Don't allow mixing except with finally, and the
> programmer has to be explicit about their intent.  That was (and
> remains) a Pythonic solution.

Why is this not an argument for disallowing multiple except blocks, like:

  try:
     raise A()
  except A:
     raise B()
  except B:
     print 'Did we get here?'

This is legal and well-defined in Python.  If try/except/finally was
removed it seems like multiple except blocks should have been removed
too--the behavior of one is as obvious as the other.