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.

Martijn Faassen <faassen@infrae.com> wrote in news:42F38FFB.2040201@infrae.com:

...

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.

Duncan, could you perhaps check in a fix? :) I'm fine with a change to the testing code to also take the wild variety of 'nan' representations into account.

I just checked in a change which ignores case when checking the representation of NaNs, so we should be good now for any of the above. Unfortunately I can't find any web pages listing all known NaN representations, so someday someone else will probably find another.