On 26 Dec, 08:06, Ram Rachum <r...@rachum.com> wrote:

Now of course, you can find other solutions to this problem. You can write a decorator to do the post-processing phase, or you could divide the whole thing into 2 functions. But I think that sometimes, the `finally`-postprocess idiom I propose will be the most succinct one.

I initially responded to say "use a decorator", but you're already aware of the common pattern for dealing with this, and yet you'd rather the language change instead?

(Regarding lack of return value and propagating exceptions: This all sounds solvable to me. Why not let the `finally` clause detect what's going on and react appropriately? No `return` value? Don't postprocess. Exception raised? Don't interfere.)

People already struggle with understanding the semantics of try/ finally - you yourself demonstrated this in your first post by not being away that the 'return value' may not be set - and you want to make it _more_ magic? You're a programmer. At the end of the day, you're going to have to do _some_ "heavy" lifting by yourself. Assign your return values to an object that performs the post-processing on demand. Create a context manager that does it when it exits. Write a loop to decorate your functions if typing @decorator is so strenuous. Making Python less clear to save yourself some typing isn't a decent trade off.