[egenix-users] Re: mx.DateTime 3.2.x and numpy

V vovansim at gmail.com
Wed Dec 21 21:18:37 CET 2011

M.-A. Lemburg <mal at ...> writes:
> We'll have to install numpy and check the problem. We may well have
> to patch mxDateTime to make it work with numpy, if this uses its
> own coercion mechanism.


I ran into the very same problem the other day. I have also found the root of 
the problem. It lies in file mx/DateTime/mxDateTime/mxDateTime.c, function 
mxDateTime_RichCompare, specifically this little bit of code:

    else if (PyFloat_Compatible(right)) {
		/* DateTime op Number -- compare ticks */
		double t1 = PyFloat_AsDouble(right);
		double t0 = mxDateTime_AsTicksWithOffset(self, 0, -1);

		if ((t0 == -1.0 || t1 == -1.0) && PyErr_Occurred())
			goto onError;

		cmp = (t0 < t1) ? -1 : (t0 > t1) ? 1 : 0;

Note here that if the thing on the left side of a comparison is an mx DateTime, 
and the thing on the right side of the comparison is a numpy array, this if 
clause will trigger (because numpy.ndarray implements a __float__ method), and 
the first thing it will attempt to do is to cast the array to a float. Now, if 
this array contains more than one element, precisely the exception that 
Christian observes will occur.

    TypeError: only length-1 arrays can be converted to Python scalars

I suppose it's somewhat of a numpy fault in that perhaps they shouldn't 
implement conversion from array to float, if it doesn't work for arrays with 
more than one element, but that behavior has been in numpy for ages, whereas I 
believe the PyFloat_Compatible check is a semi-new addition to mx DateTime.

Hope this helps, and hope you guys can find a good resolution to this. For now, 
I have to patch my local version of mx to work around this issue.


More information about the egenix-users mailing list