In a message of Tue, 15 Jun 2004 19:14:34 +0200, Jacob Hallén writes:
On tisdag 15 juni 2004 19.06, holger krekel wrote:
[Armin Rigo Tue, Jun 15, 2004 at 05:56:07PM +0100]
Hi,
Building on a suggestion by Jacob on how to safely convert old-style unittests "self.assertEquals(x,y)" into new-style utest "assert x == y": the difficulty is not to find the self.assertEquals() in the test sources, but to safely identify the comma between the two arguments, and not mistake it with some other comma that could appear in x or in y.
There was talk about subtle string parsing, or about using Python's parser or compiler package, but actually it is much easier than that. .. Just try to split the text "x,y" between the parenthesis in two halve s at every possible comma position, until both halves compile without rais ing SyntaxError :-)
Yes, that reminds me of my favourite "try-parsing" technique (used in rlcompleter2 and elsewhere :-)
Actually you also need to check for multiline-parseability first. IIRC we do have a quite a bit of multiline-asserts.
Laura has solved the try-parsing problem, so it isn't just a suggestion a ny more.
Jacob _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
I got the stuff working with compile too!(i.e. don't race out there and implement this before I get my checkin). Right now the great problem is files that look like this: .......... .......... self.assertEquals(x, y) # check for unmatched () ......... where the last ')' in the comment is the one that gets split and multi-line comments that start self.assertEquals t.ex ''' Here is something which will confuse things a lot self.assertEquals(x, y) will be converted to assert x == y ''' Right now my program will mistake that for program text to be converted. I wonder if this is a real problem for us? Also, the compile needs to get a string with the leading indentation stripped right off, i.e. self.assertEquals(x + f(y, z) + (z + 1), 42) needs to make the strings x + f(y, z) + z + 1 and 42 so as not to get a syntax error on the unexpected indentation. I wonder if we have text where people mix spaces and tabs on the leading line on purpose? If so my program is going to despair and demand a human to fix it. I will get done making dinner, then check in what I have. It was rather fun ... Thank you Armin for the idea over dinner ... Laura
[Laura Creighton Tue, Jun 15, 2004 at 07:44:54PM +0200]
I got the stuff working with compile too!(i.e. don't race out there and implement this before I get my checkin).
Right now the great problem is files that look like this:
.......... .......... self.assertEquals(x, y) # check for unmatched () .........
where the last ')' in the comment is the one that gets split and multi-line comments that start self.assertEquals t.ex
i think it makes sense to detect (and possibly preserve) comment-parts before-hand.
''' Here is something which will confuse things a lot
self.assertEquals(x, y) will be converted to assert x == y
'''
this exact thing should fail the (multiline-) parseability-test IIUC.
Also, the compile needs to get a string with the leading indentation stripped right off, i.e.
self.assertEquals(x + f(y, z) + (z + 1), 42)
needs to make the strings
x + f(y, z) + z + 1
and
42
so as not to get a syntax error on the unexpected indentation.
We should be safe with trying-to-compile "(" + part + ")" which basically lets you ignore indentation. (We only have expressions so adding parenthesis should be safe). When actually writing out the assert-statement you can do something like " ".join(expr.split()) to forget about all indentation. As a bonus it would be nice to write out multiple lines if the linewidth gets greater 75 or so. Of course parentheses are required around the expression part of such a multiline assert-statement like assert (x + verylongfunctioncall(y, z) + longvariablename + 1 == some_expected_result) cheers and have a good dinner, holger
participants (2)
-
holger krekel -
Laura Creighton