On Tue, Jul 25, 2017 at 4:47 PM, Rustom Mody <rustompm...@gmail.com> wrote:
> +1
> You can call it bug or bug-promoted-to-feature :D
>
> I call it surprising because I dont know of any other case in python where
> a delete is user-detectable
> ie python's delete of objects always works quietly behind the scenes whereas
> this adds a leakiness to the memory-management abstraction
You're conflating two things. There's nothing here that forces the
destruction of an object; the name is simply unbound. You can confirm
this from the disassembly in CPython:
>>> import dis
>>> def f():
... try: 1/0
... except Exception as e: pass
...
>>> dis.dis(f)
2 0 SETUP_EXCEPT 12 (to 14)
2 LOAD_CONST 1 (1)
4 LOAD_CONST 2 (0)
6 BINARY_TRUE_DIVIDE
8 POP_TOP
10 POP_BLOCK
12 JUMP_FORWARD 34 (to 48)
3 >> 14 DUP_TOP
16 LOAD_GLOBAL 0 (Exception)
18 COMPARE_OP 10 (exception match)
20 POP_JUMP_IF_FALSE 46
22 POP_TOP
24 STORE_FAST 0 (e)
26 POP_TOP
28 SETUP_FINALLY 6 (to 36)
30 POP_BLOCK
32 POP_EXCEPT
34 LOAD_CONST 0 (None)
>> 36 LOAD_CONST 0 (None)
38 STORE_FAST 0 (e)
40 DELETE_FAST 0 (e)
42 END_FINALLY
44 JUMP_FORWARD 2 (to 48)
>> 46 END_FINALLY
>> 48 LOAD_CONST 0 (None)
50 RETURN_VALUE
>>>
It actually does the equivalent of:
finally:
e = None
del e
In the normal case, this will leave the original exception loose and
garbage-collectable, but if it's been bound to another name, it won't.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
