[pypy-dev] utest conversion
lac at strakt.com
Tue Jun 15 20:52:22 CEST 2004
In a message of Tue, 15 Jun 2004 20:07:00 +0200, holger krekel writes:
>> 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 be
I don't see how that helps my problem, which is that of stripping the
unwanted trailing ). At any rate, before the latest refactor
self.assertEquals(x, y) # check for unmatched ()
assert x == y) # check for unmatched (
which wasn't the idea ... :-)
>> 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.
What does IIUC mean again?
>> 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),
>> needs to make the strings
>> x + f(y, z) + z + 1
>> 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).
I should have thought of that. Thank you.
>When actually writing out the assert-statement you
>can do something like
> " ".join(expr.split())
>to forget about all indentation.
I've been saving it, just as its author put it in. Since assert is shorter
than self.assertEquals, this means that whatever indentation the assertEqual
writer wanted, will get preserved.
Of course, we will see if this continues after I handle multiline comments better.
More information about the Pypy-dev