Martijn Faassen <faassen@infrae.com> wrote in news:42F1EDDA.1080303@infrae.com:
When I run "make test" I get the following error:
**** 270/300 ( 90.0%): Doctest: lxml.tests.test_xpathevaluator.xpath ====================================================================== FAIL: test_xpath_number (lxml.tests.test_xpathevaluator.ETreeXPathTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/python/lib/python2.4/unittest.py", line 260, in run testMethod() File "/webapps/local/src/python-modules/lxml/src/lxml/tests/test_xpatheva luator.py", line 20, in test_xpath_number self.assertEquals('nan', str(tree.xpath('number(/a)'))) File "/usr/local/python/lib/python2.4/unittest.py", line 333, in failUnlessEqual raise self.failureException, \ AssertionError: 'nan' != 'NaN'
---------------------------------------------------------------------- Ran 270 tests in 0.605s
FAILED (failures=1) ****
I'm using lxml 0.7, libxml2 2.6.16, libxslt 1.1.2, Python 2.4, Solaris 9.
Argh, NaN support in Python is desperately inconsistent between platforms, so I suspect this has to do with it running on Solaris... I think someone (Duncan?) fixed it on Windows at some stage too, but apparently it still fails on some other platforms. I don't really understand very well what's going on with 'nan'. Perhaps someone can puzzle this out?
The backtrace seems to be from an old version. If you checkout the latest from SVN then you will still get an Assertion error here, but it will be a different one. The new code is easier to adapt to include 'NaN' as well as 'nan'. What happens is that Python's string representation of a nan value is simply the representation used by the underlying C runtime library and that varies wildly between systems: 'nan', 'NaN', and '1.#QNAN' are probably just some of them.