I was looking through the "What's New for Python 3.3" file and I saw this example code: try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt") and I thought it would be more elegant if you could drop the try. with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt") I assume that this has already been proposed and rejected. Does anyone have a good explanation of why? ISTM that the with-statement is mostly just a way of abstracting out try-except blocks, so it might be nice to have a way of handling errors that pop up during the initialization phase instead of just the code-block phase. I guess one obvious counter argument is that naive programmers might think that the "except" applies to things in the block instead of just things in the initializer. But naive programmers think lots of wrong things. ;-)
That's a fantastic idea. As it stands context objects need to be done manually if exception handling is desired during enter. The except here could apply to the with statement only, since it's not possible to differentiate at present. Either way +1 to some consideration of Carl's proposal. On Nov 20, 2011 10:43 AM, "Carl M. Johnson" <cmjohnson.mailinglist@gmail.com> wrote:
I was looking through the "What's New for Python 3.3" file and I saw this example code:
try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
and I thought it would be more elegant if you could drop the try.
with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
I assume that this has already been proposed and rejected. Does anyone have a good explanation of why? ISTM that the with-statement is mostly just a way of abstracting out try-except blocks, so it might be nice to have a way of handling errors that pop up during the initialization phase instead of just the code-block phase.
I guess one obvious counter argument is that naive programmers might think that the "except" applies to things in the block instead of just things in the initializer. But naive programmers think lots of wrong things. ;-) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Oops, just read the rest of the proposal which said exactly this. On Nov 20, 2011 1:40 PM, "Matt Joiner" <anacrolix@gmail.com> wrote:
That's a fantastic idea. As it stands context objects need to be done manually if exception handling is desired during enter. The except here could apply to the with statement only, since it's not possible to differentiate at present. Either way +1 to some consideration of Carl's proposal. On Nov 20, 2011 10:43 AM, "Carl M. Johnson" < cmjohnson.mailinglist@gmail.com> wrote:
I was looking through the "What's New for Python 3.3" file and I saw this example code:
try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
and I thought it would be more elegant if you could drop the try.
with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
I assume that this has already been proposed and rejected. Does anyone have a good explanation of why? ISTM that the with-statement is mostly just a way of abstracting out try-except blocks, so it might be nice to have a way of handling errors that pop up during the initialization phase instead of just the code-block phase.
I guess one obvious counter argument is that naive programmers might think that the "except" applies to things in the block instead of just things in the initializer. But naive programmers think lots of wrong things. ;-) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Sat, Nov 19, 2011 at 3:43 PM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
I was looking through the "What's New for Python 3.3" file and I saw this example code:
try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
and I thought it would be more elegant if you could drop the try.
with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
Eew. No please. There seems to be a trend in proposing more random variants of the existing compound statements. Please don't do this. The existing complement of compound statements is quite sufficient and the new proposals do nothing but complicate the parser, the documentation, and the learning process for occasional users.
I assume that this has already been proposed and rejected. Does anyone have a good explanation of why?
I suppose "because I say so" is not a good explanation? :-)
ISTM that the with-statement is mostly just a way of abstracting out try-except blocks, so it might be nice to have a way of handling errors that pop up during the initialization phase instead of just the code-block phase.
Wrong. The with-statement abstracts out a try-*finally* block. A try-except cannot be replaced by a with-statement (or it would have to be a very crooked context manager).
I guess one obvious counter argument is that naive programmers might think that the "except" applies to things in the block instead of just things in the initializer. But naive programmers think lots of wrong things. ;-)
That's actually a deal killer right there. (If it wasn't born dead, that is. :-) Your proposal above, through it "this could be equivalent to that" example, makes it seem like the except block applies to the entire with-statement. But here you appear to say that an error in the body of the with-block would not be covered? And your example use of exceptions that are only raised by open() strengthens this. If a proposal manages to confuse even its proposer, perhaps that is enough to reject it? -- --Guido van Rossum (python.org/~guido)
On 11/19/2011 6:43 PM, Carl M. Johnson wrote:
I was looking through the "What's New for Python 3.3" file and I saw this example code:
try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
and I thought it would be more elegant if you could drop the try.
with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
This saves one short line. That is insufficient reason for a puzzling construct. -- Terry Jan Reedy
On Sun, Nov 20, 2011 at 9:43 AM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
I was looking through the "What's New for Python 3.3" file and I saw this example code:
try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt")
Hmm, this code is dubious, as the scope of the try block is too broad. It should really be written so it only covers the creation of the file object: try: f = open("document.txt") except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt") else: with f: content = f.read() At that point, it's hopefully clearer why this proposal doesn't make sense. (A tracker issue suggesting that the What's New example be updated wouldn't hurt, though). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Carl M. Johnson
-
Guido van Rossum
-
Matt Joiner
-
Nick Coghlan
-
Terry Reedy