Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!border2.nntp.ams2.giganews.com!border1.nntp.ams2.giganews.com!backlog3.nntp.ams3.giganews.com!backlog3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
From: =?utf-8?B?R8O2a3R1xJ8=?= Kayaalp <self@gkayaalp.com>
To: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Try-except-finally paradox
References: <9314ac52-a2be-4382-94ef-2c291f32be1a@googlegroups.com> <lcdf0c$bnl$2@ger.gmane.org> <lcfc58$bep$1@ger.gmane.org>
Date: Sat, 01 Feb 2014 03:58:19 +0200
In-Reply-To: <lcfc58$bep$1@ger.gmane.org> (Terry Reedy's message of "Fri, 31 Jan 2014 00:26:05 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.6247.1391223064.18130.python-list@python.org>
Lines: 106
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:65169

Terry Reedy <tjreedy@udel.edu> writes:

I do not have any information on the topic, but I *imagine* that the
when RETURN_VALUE opcode is evaluated within the context of an except
block, it triggers a check for whether a corresponding finally block
exists and should it exist, it is triggered, much like a callback.
So, my *imaginary* algorithm works like this:

return:
  if within an except block EB:
    if EB has a correspoinding final block FB
      run FB
    else
      do return
  else
    do return

In Jessica's example, as the finally block executes a RETURN_VALUE
opcode, and as this is *probably* a jump to the caller, the rest of the
code does not get a chance to be executed.

As I have said earlier, I by no means assert the truth of this idea I've
explained here, but it seems quite reasonable to me.

          gk

> On 1/30/2014 7:05 AM, Dave Angel wrote:
>>   Jessica Ross <deathweasel@gmail.com> Wrote in message:
>>> I found something like this in a StackOverflow discussion.
>>>>>> def paradox():
>>> ...     try:
>>> ...             raise Exception("Exception raised during try")
>>> ...     except:
>>> ...             print "Except after try"
>>> ...             return True
>>> ...     finally:
>>> ...             print "Finally"
>>> ...             return False
>>> ...     return None
>>> ...
>>>>>> return_val = paradox()
>>> Except after try
>>> Finally
>>>>>> return_val
>>> False
>>>
>>> I understand most of this.
>>> What I don't understand is why this returns False rather than True. Does the finally short-circuit the return in the except block?
>>>
>>
>> The finally has to happen before any return inside the try or the
>>   except.  And once you're in the finally clause you'll finish it
>>   before resuming the except clause.  Since it has a return,  that
>>   will happen before the other returns. The one in the except block
>>   will never get reached.
>>
>> It's the only reasonable behavior., to my mind.
>
> Checking with the disassembled code, it appears that the except return
> happens first and is then caught and the value over-written
>
>   2           0 SETUP_FINALLY           45 (to 48)
>               3 SETUP_EXCEPT            16 (to 22)
>
>   3           6 LOAD_GLOBAL              0 (Exception)
>               9 LOAD_CONST               1 ('Exception raised during try')
>              12 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
>              15 RAISE_VARARGS            1
>              18 POP_BLOCK
>              19 JUMP_FORWARD            22 (to 44)
>
>   4     >>   22 POP_TOP
>              23 POP_TOP
>              24 POP_TOP
>
>   5          25 LOAD_GLOBAL              1 (print)
>              28 LOAD_CONST               2 ('Except after try')
>              31 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
>              34 POP_TOP
>
>   6          35 LOAD_CONST               3 (True)
>              38 RETURN_VALUE
>              39 POP_EXCEPT
>              40 JUMP_FORWARD             1 (to 44)
>              43 END_FINALLY
>         >>   44 POP_BLOCK
>              45 LOAD_CONST               0 (None)
>
>   8     >>   48 LOAD_GLOBAL              1 (print)
>              51 LOAD_CONST               4 ('Finally')
>              54 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
>              57 POP_TOP
>
>   9          58 LOAD_CONST               5 (False)
>              61 RETURN_VALUE
>              62 END_FINALLY
>
>  10          63 LOAD_CONST               0 (None)
>              66 RETURN_VALUE
>
>
>
>
> -- 
> Terry Jan Reedy