On 2017-07-25 09:28, Chris Angelico wrote: > 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
I wonder why it would bother to load None... (as someone not very familiar with Python at the bytecode level) -- Thomas > 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
