Inline 'raises' expression

Hi, It happens that I'm just interested in whether an expression raises an exception, not the return value. This might look something like try: check_status() except IOError: cleanup() which could be written more simply as if check_status() raises IOError: cleanup() Also, instead of the inconvenient self.assertRaises(ZeroDivisionError, lambda: 1/0) one could just write assert 1/0 raises ZeroDivisionError Something like this would especially be useful for those of us who aren't fans of the unittest framework. Alternatively, just the assert--raises form could be permitted. Thoughts? Fredrik

Raymond Hettinger wrote:
+1 And to do the same thing in other ways isn't as easy as it seems. Regarding ignoring asserts by -O, Would it be possible to change asserts so they default to off instead of on? I'd rather have -debug set __debug__ to True rather than -0 setting it to False. Personally I'd like asserts to be part of the testing framework. ie... they are *always skipped* unless possibly a -test or -debug flag is specified. Another useful feature would be to specify where asserts sends it's error. What I'd like to do is to be able to sprinkle asserts throughout my code as a way to do simple tests and then possibly ... python -debug module.py ... enable asserts to output to stderr Or to use plain asserts effectively in unittests and doctests ... python -test module.py ... enamble asserts and run unittests or doctests for module. python -test ... run python test suite Is it too late to go this direction for 3.0, 3.1... ? Ron

Fredrik Johansson schrieb:
I think an extra syntax for such an easy task is unnecessary. The following function emulates this functionality sufficiently: def raises(f,e): try: f() except e: return True except: return False else: return False def f(x): if x != 2: raise ValueError()

On Sun, Aug 24, 2008 at 4:01 PM, Paul Hankin <paul.hankin@pobox.com> wrote:
True, but that's a lot of noise for something very simple. And the extra required "lambda:" makes the "raises" expression much less readable. On Mon, Aug 25, 2008 at 1:47 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Good point, though I've never personally felt the need to run Python with assertions turned off. (It would arguably be more useful if assertions were enabled on a per module basis, but this is a tangential matter.) Fredrik

On 24 Ago, 12:43, "Fredrik Johansson" <fredrik.johans...@gmail.com> wrote:
+1, I really like it. --- Giampaolo http://code.google.com/p/pyftpdlib/

On Sun, Aug 24, 2008 at 3:43 AM, Fredrik Johansson <fredrik.johansson@gmail.com> wrote:
If you need to add handling for another type of exception, you have to totally restructure your code. It's no longer a matter of adding another except statement to the chain. Also, what do you do if you need to use the exception instance? Are you proposing (by implication) the additional syntax "if check_status() raises IOError as foo:"? What If I want multiple statements to be guarded by the try block? Again, I have to switch mechanisms.
I rarely find myself only caring about the type of the exception. For anything complex, I want to make some assertion about the attributes/structure of the raised exception, for example, regexing the exception's str() value. If I want to change from only caring about the type of the exception (the syntax you propose above) to caring about the contents/structure of the exception instance, I have to completely change which mechanism I'm using. With this proposal I can't gracefully go from doing something simple to doing something complex. -1 Collin Winter

Raymond Hettinger wrote:
+1 And to do the same thing in other ways isn't as easy as it seems. Regarding ignoring asserts by -O, Would it be possible to change asserts so they default to off instead of on? I'd rather have -debug set __debug__ to True rather than -0 setting it to False. Personally I'd like asserts to be part of the testing framework. ie... they are *always skipped* unless possibly a -test or -debug flag is specified. Another useful feature would be to specify where asserts sends it's error. What I'd like to do is to be able to sprinkle asserts throughout my code as a way to do simple tests and then possibly ... python -debug module.py ... enable asserts to output to stderr Or to use plain asserts effectively in unittests and doctests ... python -test module.py ... enamble asserts and run unittests or doctests for module. python -test ... run python test suite Is it too late to go this direction for 3.0, 3.1... ? Ron

Fredrik Johansson schrieb:
I think an extra syntax for such an easy task is unnecessary. The following function emulates this functionality sufficiently: def raises(f,e): try: f() except e: return True except: return False else: return False def f(x): if x != 2: raise ValueError()

On Sun, Aug 24, 2008 at 4:01 PM, Paul Hankin <paul.hankin@pobox.com> wrote:
True, but that's a lot of noise for something very simple. And the extra required "lambda:" makes the "raises" expression much less readable. On Mon, Aug 25, 2008 at 1:47 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Good point, though I've never personally felt the need to run Python with assertions turned off. (It would arguably be more useful if assertions were enabled on a per module basis, but this is a tangential matter.) Fredrik

On 24 Ago, 12:43, "Fredrik Johansson" <fredrik.johans...@gmail.com> wrote:
+1, I really like it. --- Giampaolo http://code.google.com/p/pyftpdlib/

On Sun, Aug 24, 2008 at 3:43 AM, Fredrik Johansson <fredrik.johansson@gmail.com> wrote:
If you need to add handling for another type of exception, you have to totally restructure your code. It's no longer a matter of adding another except statement to the chain. Also, what do you do if you need to use the exception instance? Are you proposing (by implication) the additional syntax "if check_status() raises IOError as foo:"? What If I want multiple statements to be guarded by the try block? Again, I have to switch mechanisms.
I rarely find myself only caring about the type of the exception. For anything complex, I want to make some assertion about the attributes/structure of the raised exception, for example, regexing the exception's str() value. If I want to change from only caring about the type of the exception (the syntax you propose above) to caring about the contents/structure of the exception instance, I have to completely change which mechanism I'm using. With this proposal I can't gracefully go from doing something simple to doing something complex. -1 Collin Winter
participants (9)
-
BJörn Lindqvist
-
Collin Winter
-
Fredrik Johansson
-
Georg Brandl
-
Giampaolo Rodola'
-
Greg Ewing
-
Mathias Panzenböck
-
Raymond Hettinger
-
Ron Adam