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

[V]

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
> fails.

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.