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
From: "Fredrik Johansson" fredrik.johansson@gmail.com
one could just write
assert 1/0 raises ZeroDivisionError
+1
This would be a nice extension to the assertion syntax.
Raymond
Raymond Hettinger wrote:
From: "Fredrik Johansson" fredrik.johansson@gmail.com
one could just write
assert 1/0 raises ZeroDivisionError
+1
This would be a nice extension to the assertion syntax.
+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
Raymond Hettinger schrieb:
From: "Fredrik Johansson" fredrik.johansson@gmail.com
one could just write
assert 1/0 raises ZeroDivisionError
+1
This would be a nice extension to the assertion syntax.
It certainly looks good, and is probably implemented quickly. However, it introduces a new pseudo-keyword, like "as" was in the past, as we certainly don't want to make "raises" a "full" one.
Georg
Fredrik Johansson schrieb:
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 ZeroDivisionErrorSomething 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
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()
raises(lambda:f(1),ValueError)
True
raises(lambda:f(2),ValueError)
False
raises(lambda:f(1),Exception)
True
raises(lambda:f(2),Exception)
False
raises(lambda:f(1),TypeError)
False
raises(lambda:f(2),TypeError)
False
On Sun, Aug 24, 2008 at 4:01 PM, Paul Hankin paul.hankin@pobox.com wrote:
There's not much need for a language modification; you can code it up directly. The obvious problem with what you want is that it's only good if you want to catch a single exception.
def raises(thunk, exn): try: thunk() return False except exn: return True
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:
Fredrik Johansson wrote:
one could just write
assert 1/0 raises ZeroDivisionError
It's been pointed out that using assert for testing is not the best idea, since then you can't test that the code works properly with assertions turned off.
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:
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 _______________________________________________ Python-ideas mailing list Python-id...@python.orghttp://mail.python.org/mailman/listinfo/python-ideas
+1, I really like it.
--- Giampaolo http://code.google.com/p/pyftpdlib/
2008/8/24 Fredrik Johansson fredrik.johansson@gmail.com:
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()
Seems like a bad example to me. Wouldn't you rather write:
try: check_status() finally: cleanup()
??
On Sun, Aug 24, 2008 at 3:43 AM, Fredrik Johansson fredrik.johansson@gmail.com wrote:
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()
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.
Also, instead of the inconvenient
self.assertRaises(ZeroDivisionError, lambda: 1/0)
one could just write
assert 1/0 raises ZeroDivisionError
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
-
BJörn Lindqvist -
Collin Winter -
Fredrik Johansson -
Georg Brandl -
Giampaolo Rodola' -
Greg Ewing -
Mathias Panzenböck -
Raymond Hettinger -
Ron Adam