Re: [Python-ideas] Allow accessing return value inside finally clause
On 26 Dec, 10:44, Ram Rachum <r...@rachum.com> wrote:
I don't think that this makes Python less clear;
How can you possibly say this? You've changed the `finally` clause from _guaranteed_ execution to something utterly inconsistent. In fact, finally blocks would need to have _more_ code to guard against all of the different execution models you're proposing here. I'm not sure why you think forcing me to write more & less obvious code in a finally block is a better trade off than you making clear, explicit use of decorators. Ambiguity does not equate to clarity. Less typing doesn't either. Creating small re-usable pieces of code that do the "hard work" for you, however, _is a lot more clear_.
I think it's just another minor feature that might be useful for some people, and for people who don't, it won't matter. How many people use the `for..else` feature, for example? Very, very few people do. I've used it only several times. But it's still part of Python because it helps in a few rare cases, so that makes it worth it *despite* the fact that it might confuse a newbie.
The behaviour of `for..else` doesn't change based on arbitrary conditions, whereas what you propose is that the finally blocks behaviour is _fundamentally_ different depending on whether the try block is fully executed or not, whether an exception is raised or not. This is absolutely not the same thing, and trying to pass this concern off as "confusing to newbies" is rather disingenuous. The behaviour would be _confusing to everybody_. This is not a valid cost to save you from having to type a few more keystrokes to decorate the return value.
Raum, please make sure you reply on-list. I cannot see your replies here. On Tue, Dec 25, 2012 at 10:09 PM, alex23 <wuwei23@gmail.com> wrote:
On 26 Dec, 10:44, Ram Rachum <r...@rachum.com> wrote:
I don't think that this makes Python less clear;
How can you possibly say this?
You've changed the `finally` clause from _guaranteed_ execution to something utterly inconsistent. In fact, finally blocks would need to have _more_ code to guard against all of the different execution models you're proposing here. I'm not sure why you think forcing me to write more & less obvious code in a finally block is a better trade off than you making clear, explicit use of decorators.
Ambiguity does not equate to clarity. Less typing doesn't either. Creating small re-usable pieces of code that do the "hard work" for you, however, _is a lot more clear_.
I think it's just another minor feature that might be useful for some people, and for people who don't, it won't matter. How many people use the `for..else` feature, for example? Very, very few people do. I've used it only several times. But it's still part of Python because it helps in a few rare cases, so that makes it worth it *despite* the fact that it might confuse a newbie.
The behaviour of `for..else` doesn't change based on arbitrary conditions, whereas what you propose is that the finally blocks behaviour is _fundamentally_ different depending on whether the try block is fully executed or not, whether an exception is raised or not. This is absolutely not the same thing, and trying to pass this concern off as "confusing to newbies" is rather disingenuous. The behaviour would be _confusing to everybody_.
This is not a valid cost to save you from having to type a few more keystrokes to decorate the return value. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Jasper
participants (2)
-
alex23 -
Jasper St. Pierre