[Python-Dev] Can Python implementations reject semantically invalid expressions? (original) (raw)

Craig Citro craigcitro at gmail.com
Fri Jul 2 19:28:52 CEST 2010

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

More information about the Python-Dev mailing list