Implied try blocks

Given that for some time the try/except/else form is standard and encouraged, I've found the following pattern really common in my code: try: r = some_single_statement() except TypeError: print "oh no!" raise OhNoException() else: p = prepare(r) print "I got", p Where the try block ever doing more than one thing feels dangerous or sloppy, because I want to make sure I know exactly where the exception comes from. The else block becomes the long tail and the try is just the head. This makes the try block itself seem heavy. What if we allowed this to be implied and except/else blocks bound to the previous statement? A try block would be an optional form, and mostly left for multi-block try's r = some_single_statement() except TypeError: print "oh no!" raise OhNoException() else: p = prepare(r) print "I got", p I think it reads acceptably. With a try: block your eye leads up right to that one statement. There is no ambiguity to deal with, that I can tell. I'm not sure if this is a great idea, but I don't dislike it. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

Calvin Spealman wrote:
In this case, the "else" is not required. This could be written more simply as: try: r = some_single_statement() except TypeError: print "oh no!" raise OhNoException() p = prepare(r) print "I got", p The else is only required when the except blocks don't exit via a return or raise. Otherwise, you can just continue outside of the try...except block.
Huh? The try block is two lines, one if you don't count the "try" itself. How is that heavy?
-1 With the current syntax, when reading code, you know when you enter a try block because you read "try:" just before the block begins. With your suggestion, the try is a booby-trap for the unwary. You're reading code, you read the "r = ..." line which looks like a normal line outside of a try block, and then *blam* you trip over the "except" and have to mentally backtrack and re-interpret the previous line "oh, it's actually inside a try block -- an invisible try block". In my opinion, this sort of implicit change of semantics is exactly the kind of thing that the Zen of Python warns us against. Your suggestion will also mask errors: try: do_stuff() except NameError: first_except_block() except ValueError: second_except_block() and_another_line() and_a_third_line() # oops, I forgot to indent except TypeError: ... Currently, this will be a SyntaxError. With your suggestion, it will silently do the wrong thing. -- Steven

On Sun, Mar 25, 2012 at 5:15 PM, Calvin Spealman <ironfroggy@gmail.com> wrote:
-1, because.. When I reading this and encounter "except TypeError", I have to update the code that I've already read (the stuff in my head) to place it into exception handling block. That's a good anti-pattern for readability. -- anatoly t.

On Mon, Mar 26, 2012 at 6:59 AM, anatoly techtonik <techtonik@gmail.com> wrote:
The idea i was hoping to pull off here is that every statement was, implicitly, a try block and any exception raised by it could have handlers associated, and a block that would only follow if it did not raise an exception. However, I never thought it was a great idea, but this is python-ideas not python-good-ideas ;-) Steven has already convinced me it was a bad idea from a maintenance standpoint.
-- anatoly t.
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

On 03/26/2012 12:59 PM, anatoly techtonik wrote:
Slightly off topic: And that's why I stopped to write "f() if g()" in Ruby and use the more verbose "if g(); f(); end" there. At first it looks like a nice small syntax, but then it turns out to severely hurt readability. I even found code like this once: begin # quite some lines of code rescue # more code end unless something.nil? Yes, the whole block is actually conditional. I think syntax, that requires you to update already parsed code is bad.

Calvin Spealman wrote:
In this case, the "else" is not required. This could be written more simply as: try: r = some_single_statement() except TypeError: print "oh no!" raise OhNoException() p = prepare(r) print "I got", p The else is only required when the except blocks don't exit via a return or raise. Otherwise, you can just continue outside of the try...except block.
Huh? The try block is two lines, one if you don't count the "try" itself. How is that heavy?
-1 With the current syntax, when reading code, you know when you enter a try block because you read "try:" just before the block begins. With your suggestion, the try is a booby-trap for the unwary. You're reading code, you read the "r = ..." line which looks like a normal line outside of a try block, and then *blam* you trip over the "except" and have to mentally backtrack and re-interpret the previous line "oh, it's actually inside a try block -- an invisible try block". In my opinion, this sort of implicit change of semantics is exactly the kind of thing that the Zen of Python warns us against. Your suggestion will also mask errors: try: do_stuff() except NameError: first_except_block() except ValueError: second_except_block() and_another_line() and_a_third_line() # oops, I forgot to indent except TypeError: ... Currently, this will be a SyntaxError. With your suggestion, it will silently do the wrong thing. -- Steven

On Sun, Mar 25, 2012 at 5:15 PM, Calvin Spealman <ironfroggy@gmail.com> wrote:
-1, because.. When I reading this and encounter "except TypeError", I have to update the code that I've already read (the stuff in my head) to place it into exception handling block. That's a good anti-pattern for readability. -- anatoly t.

On Mon, Mar 26, 2012 at 6:59 AM, anatoly techtonik <techtonik@gmail.com> wrote:
The idea i was hoping to pull off here is that every statement was, implicitly, a try block and any exception raised by it could have handlers associated, and a block that would only follow if it did not raise an exception. However, I never thought it was a great idea, but this is python-ideas not python-good-ideas ;-) Steven has already convinced me it was a bad idea from a maintenance standpoint.
-- anatoly t.
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

On 03/26/2012 12:59 PM, anatoly techtonik wrote:
Slightly off topic: And that's why I stopped to write "f() if g()" in Ruby and use the more verbose "if g(); f(); end" there. At first it looks like a nice small syntax, but then it turns out to severely hurt readability. I even found code like this once: begin # quite some lines of code rescue # more code end unless something.nil? Yes, the whole block is actually conditional. I think syntax, that requires you to update already parsed code is bad.
participants (6)
-
anatoly techtonik
-
Antoine Pitrou
-
Calvin Spealman
-
Masklinn
-
Mathias Panzenböck
-
Steven D'Aprano