[Numpy-discussion] longlong format error with Python <= 2.6 in scalartypes.c
Thu Aug 18 23:01:42 CDT 2011
On Thu, Aug 4, 2011 at 4:08 PM, Derek Homeier <
> commits c15a807e and c135371e (thus most immediately addressed to Mark, but
> I am sending this to the list hoping for more insight on the issue)
> introduce a test failure with Python 2.5+2.6 on Mac:
> FAIL: test_timedelta_scalar_construction (test_datetime.TestDateTime)
> Traceback (most recent call last):
> line 219, in test_timedelta_scalar_construction
> assert_equal(str(np.timedelta64(3, 's')), '3 seconds')
> File "/Users/derek/lib/python2.6/site-packages/numpy/testing/utils.py",
> line 313, in assert_equal
> raise AssertionError(msg)
> Items are not equal:
> ACTUAL: '%lld seconds'
> DESIRED: '3 seconds'
> due to the "lld" format passed to PyUString_FromFormat in scalartypes.c.
> In the current npy_common.h I found the comment
> * in Python 2.6 the %lld formatter is not supported. In this
> * case we work around the problem by using the %zd formatter.
> though I did not notice that problem when I cleaned up the NPY_LONGLONG_FMT
> definitions in that file (and it is not entirely clear whether the comment
> only pertains to Windows...). Anyway changing the formatters in
> scalartypes.c to "zd" as well removes the failure and still works with
> Python 2.7 and 3.2 (at least on Mac OS). However I am wondering if
> a) NPY_[U]LONGLONG_FMT should also be defined conditional to the Python
> version (and if "%zu" is a valid formatter), and
> b) scalartypes.c should use NPY_LONGLONG_FMT from npy_common.h
> I am attaching a patch implementing a), but only the quick and dirty
> solution to b).
I've touched this stuff as little as possible, because I rather dislike the
way the *_FMT macros are set up right now. I added a comment about
NPY_INTP_FMT in npy_common.h which I see you read. If you're going to try to
fix this, I hope you fix it deeper than this patch so it's not error-prone
NPY_INTP_FMT is used together with PyErr_Format/PyString_FromFormat, whereas
the other *_FMT are used with the *printf functions from the C libraries.
These are not compatible, and the %zd hack was put in place because it
exists even in Python 2.4, and Py_ssize_t seems matches the pointer size in
all CPython versions.
Switching the timedelta64 format in scalartypes.c.src to "%zd" won't help on
32-bit platforms, because it won't be a 64-bit type there, unlike how it
works ok for the NPY_INTP_FMT. In summary:
* There need to be changes to create a clear distinction between the *_FMT
for PyString_FromFormat vs the *_FMT for C library *printf functions
* I suspect we're out of luck for 32-bit older versions of CPython with
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion