Author catalin.iacob
Recipients Aaron.Meurer, VPeric, benjamin.peterson, catalin.iacob, eric.araujo, petri.lehtinen
Date 2011-08-14.18:01:26
SpamBayes Score 6.114e-13
Marked as misclassified No
Message-id <1313344888.08.0.890537142507.issue12611@psf.upfronthosting.co.za>
In-reply-to
Content
I looked at this and understood why it's happening. I don't know exactly how to fix it though, so here's what I found out.

When a doctest appears in a docstring at line n in a file, RefactorTool.parse_block will return a tree corresponding to n - 1 newline characters followed by the code in the doctest. That tree is refactored by RefactoringTool.refactor_tree which usually returns n - 1 newline characters followed by the refactored doctest. However, for the reduce fixer, the tree returned by refactor_tree starts with from functools import reduce followed by n - 1 newline characters and then the doctest reduce line. The failing assert happens when stripping those newlines because they are expected to be at the beginning of the output while in reality they're after the import line.

So the problem is a mismatch between the expectations of the doctest machinery (refactoring code that starts with some newlines results in code that starts with the same number of newlines) and the reduce fixer which adds an import, imports are added at the beginning of the file, therefore something appears before the newlines. Other fixers could exhibit the same problem.
History
Date User Action Args
2011-08-14 18:01:28catalin.iacobsetrecipients: + catalin.iacob, benjamin.peterson, eric.araujo, VPeric, Aaron.Meurer, petri.lehtinen
2011-08-14 18:01:28catalin.iacobsetmessageid: <1313344888.08.0.890537142507.issue12611@psf.upfronthosting.co.za>
2011-08-14 18:01:27catalin.iacoblinkissue12611 messages
2011-08-14 18:01:26catalin.iacobcreate