[lxml-dev] lxml.doctestcompare
I figured out why the tests fail when run in series, when using lxml.(html.)usedoctest -- since it works on import, the import is only run once. After that the module isn't really imported again, so the code that executes on import isn't run. I don't know if there's any feasible way around this. Well, I could unload the module when the doctest is through, just like I unload my OutputChecker hack. That might be okay. Bah. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers
Ian Bicking wrote:
I figured out why the tests fail when run in series, when using lxml.(html.)usedoctest -- since it works on import, the import is only run once. After that the module isn't really imported again, so the code that executes on import isn't run.
I don't know if there's any feasible way around this. Well, I could unload the module when the doctest is through, just like I unload my OutputChecker hack. That might be okay. Bah.
I put in a hack for this too. It's getting more and more ugly, but I place the blame firmly on doctest. I was trying to review some changes Stefan made, and got this: $ svn diff -r43989:44015 \ http://codespeak.net/svn/lxml/branch/html/src/lxml/html/clean.py svn: REPORT request failed on '/svn/!svn/bc/44056/lxml/branch/html/src/lxml/html/clean.py' svn: File not found: revision 43853, path '/lxml/trunk/src/lxml/html/clean.py' I don't understand that. That file hasn't been moved. What am I missing? -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers
Hi Ian, Ian Bicking wrote:
$ svn diff -r43989:44015 \ http://codespeak.net/svn/lxml/branch/html/src/lxml/html/clean.py
svn: REPORT request failed on '/svn/!svn/bc/44056/lxml/branch/html/src/lxml/html/clean.py' svn: File not found: revision 43853, path '/lxml/trunk/src/lxml/html/clean.py'
I get the same, and I'm puzzled, too. Philipp, can you look into this? There seems to be something strange going on with the SVN repository. Stefan
Hi Ian, Ian Bicking wrote:
I was trying to review some changes Stefan made
I was just refactoring. It's generally better to avoid isolated calls to * el.xpath() -> use XPath() or, even better, el.getiterator() if possible * el.attrib -> use el.set() and el.get() Obviously, that's only in the cases where the replacement is equivalent. But, for example, looping over "el.getiterator(tag)" is much faster than iterating over "el.xpath('descendant-or-self:tag')". I actually think that code even becomes simpler and thus more readable that way. For more advanced expressions, XPath() allows you to use readable function names instead of the less readable XPath expression. Stefan
participants (2)
-
Ian Bicking -
Stefan Behnel