try: finally: question

[Tim Peters]

[Peter Hansen]
>> I understand that you are arguing that it would be nicer to
>> allow try/finally/except.  I agree!  Unfortunately, (a) it was
>> removed and is probably unlikely to be added back in, (b) it
>> was ambiguous, and the ambiguity has not been resolved, so
>> until you or someone else can come up with a better approach
>> (and write a PEP) it will stay the way it is.  And that's just
>> another fact, so it's pointless to try to argue against it.

[Mark 'Kamikaze' Hughes]
>  In Java, try...catch...finally has a very clearly defined order: the
> try block is performed, if there's an exception it goes to the first
> matching catch, and then whether or not there was an exception, the
> finally block is performed.

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.