> To test that adding a string to an integer raises TypeError at
> runtime. That is, something along the lines of:
>
> with self.assertRaises(TypeError):
> 1 + "1"
>
Well, this would just mean the test suite would have to change -- that
test would become something like
with self.assertRaises(TypeError):
import operator
operator.add(1, "1")
Of course, checking that the literal syntax now raises a compile error
could be ugly:
with self.assertRaises(CompileError):
eval('1 + "1"')
... or it could move to test_parser. ;)
> If an end user is doing it rather than an implementation's own test
> suite... well, I have no idea why anyone else would want to do that :)
>
Exactly -- and if it's a clear win for users, I don't think "it makes
test-writing harder but not impossible" should really be a
counter-argument. Of course, "there's lots of existing code it would
break" is a very good counter-argument ... maybe Py4k. ;)
> It's definitely something of a grey area. The existing test suite
> would likely fail if "obviously insane" operations between literals
> started throwing SyntaxError, but it would be possible to classify
> some of those tests as implementation specific. However, an
> implementation that did that would need to completely fork any
> affected parts of the test suite, since the implementation specific
> test decorators won't help protect against failures to compile the
> code.
>
Well, I think there's some momentum towards splitting some of the
tests into Python-standard and implementation-specific things, so that
they can get shared between implementations, right? As long as clear
lines are drawn, isn't it just a question of which bucket these tests
go into?
-cc
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
