[egenix-users] Re: mx.DateTime 3.2.x and numpy
vovansim at gmail.com
Wed Dec 21 22:00:33 CET 2011
M.-A. Lemburg <mal at ...> writes:
> Not really, but it's possible that the new per operation
> coercion code does things in a different order.
That's possible. I'm in the process of upgrading from an older version of
python/numpy/mx, and all those data types used to live together nicely. So must
be some new behavior, somewhere...
> Do you get the same exception when swapping the two arguments ? ...
No, when I swap the order, then it actually works. I did some debugging, and it
looks like when the order is switched, then the code never really hits the mx
DateTime code with the array, but only with individual elements of the array. My
guess is that this is so because it goes to the numpy code first, which does an
element-by-element comparison for the scalar on the right.
> I guess we will either have to add a special case for numpy arrays
> or fallback to try other methods in case conversion to a float
Yes, I was thinking about that. I think probably that both of those options are
"not ideal" from a software engineering point of view. Perhaps, as a first step
you guys could just make the error message a bit more robust. I had a hell of a
time looking through C code to figure out what went wrong, but it would have
been easier if the message said something like this:
[Some Exception]: Could not compare DateTime with <numpy.ndarray>, which
failed to convert to float with error: [TypeError: only length-1 arrays can be
converted to Python scalars]
I think there's enough information in that function to make an error message
like this, and at least it would be immediately clear that the exception is not
actually coming from mx code, but from something it tries to do to an object
that says it's convertible to float, but actually throws an exception when
attempting said conversion.
More information about the egenix-users