try: finally: question

[OKB (not okblacke)]

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.

Out of curiosity, what would be wrong with allowing both, but
insisting that the finally block (if it exists ) must come last? The
code layout would then clearly suggest the semantics: the finally comes
last. This is the thing I most often want to write anyway.


--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Tim Peters]

[Tim]
[OKB (not okblacke)]

Out of curiosity, what would be wrong with allowing both, but
insisting that the finally block (if it exists ) must come last?

Please read the thread from its start. That *is* what Python used to do.

 

[OKB (not okblacke)]

[OKB (not okblacke)]

Out of curiosity, what would be wrong with allowing both,
but insisting that the finally block (if it exists ) must
come last?

Please read the thread from its start. That *is* what Python used
to do.

Oh, ok. The only message I've seen in this thread describing the
behavior was:

[Peter Hansen]

For example, if an exception were raised in a finally clause which
came just before the except clause, would the except clause catch it?

Which seems to be saying that finally clauses could come before
except clauses.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Peter Hansen]

Oh, ok. The only message I've seen in this thread describing the
behavior was:

[Peter Hansen]

For example, if an exception were raised in a finally clause which
came just before the except clause, would the except clause catch it?

Which seems to be saying that finally clauses could come before
except clauses.

No, it seems to be a question, clearly (now that Tim has spoken)
showing my ignorance on the subject. I never saw Python before this
feature was removed, so you can't take a question from me as being
in any way authoritative about the features it asks about...

-Peter

 

[Joshua Marshall]

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.

 

[Tim Peters]

[Joshua Marshall]

Why is this not an argument

'finally' wasn't removed based on "an argument", it was removed based
on negative feedback from real experience. What you give here
certainly is "an argument", but this wasn't an argument-based
decision.

for disallowing multiple except blocks, like:>

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

Because there's no evidence that anyone is confused by this in
practice. There was ample evidence that many people were confused in
practice when a 'finally' clause was allowed too.

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.

So you say, but experience said otherwise. You can speculate about
why if you want to, but it's a fact -- for whatever reason, Python
programmers in real life are not confused by multiple 'except' blocks,
but were confused about the semantics of allowing 'finally' too at the
same level. No amount of argument can change that -- it was an
observation, not a deduction.

 

[Jeff Shannon]

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.

I'd like to note that, in this case, exactly one of the except blocks
gets executed. If an exception is raised within one of the branches, it
doesn't get caught by later branches.

In the 'finally' case, it's unclear whether it should catch such a
secondary exception or not. On the one hand, we have the established
precedent that an exception within an exception handler goes up to the
caller. On the other hand, we have the expectation that 'finally'
should always be executed when leaving the specified code block. But
which block is being specified -- just the 'try' section, or all of the
'except' clauses as well? Syntactically, it seems that try-clause-only
should be the correct answer, but including all of the except clauses
would be the most common desire...

Given the different semantics of finally vs except, I can certainly see
a *lot* of room for confusion.

Jeff Shannon
Technician/Programmer
Credit International