Why is SETUP_FINALLY uninterruptable[sic]?

[David Pokorny]

"Jeff Epler" <jepler at unpythonic.net> wrote in message
news:mailman.1836.1092794238.5135.python-list at python.org...

>I suspect that this has something to do with code like
>
>    l = some_lock()
>    l.acquire()
>                    # MARK
>    try:
>        something with l held
>    finally:
>        l.release()
>If an asynchronous exception happens betwen l.acquire() and the
>SETUP_FINALLY opcode (at "MARK") , there's no guarantee that l.release()
>is executed.
>
>This state of affairs always existed with KeyboardInterrupt and/or
>signals, and it's hard to see how this fixes the problem if l.acquire()
>is Python code, but I think that's what's going on.

I would belive you, but there is a trivial modification that circumvents
this problem:

---begin---
mylock = some_lock()

try:
    mylock.acquire()
    something with mylock held
finally:
    mylock.release()
---end---

Now if you're saying that lots of people wrote code as above and
uninterruptibility was added to ensure that it wouldn't break, that's one
thing, but is this the ONLY reason SETUP_FINALLY is uninterruptible? This
seems improbable, especially since putting statements adjacent to #MARK will
break this code.

David