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

M.-A. Lemburg mal at egenix.com
Tue Jan 3 22:27:34 CET 2012

Christian Marquardt wrote:
> Would you have a patch available for the current release? We have a medium size application that uses mx.DateTime quite extensively with numpy, and it would add a real world test...

That would be great !

We've uploaded a snapshot with the patch to our download


Please give it a try.

Marc-Andre Lemburg
eGenix.com Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

> Thanks,
>    Christian. 
> On 3 Jan 2012, at 20:08, "M.-A. Lemburg" <mal at egenix.com> wrote:
>> V wrote:
>>> 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.
>> Right, that's how it works and I expected the switch in order
>> to resolve the problem.
>>>> 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.
>> We've settled on simply giving up in case of an error. In such
>> a case, we clear the error and let the right argument deal with the
>> operation. This solves the problem with numpy and should also resolve
>> similar problems with other types that expose __float__/nb_float
>> slots, but only implement the operation for a few special cases.
>> This may in some cases hide errors, but at least we don't have
>> to add workarounds for numpy arrays or other similar types.
>> We'll have the fix in version 3.2.2 of egenix-mx-base.
>> BTW: If you know that a data types behaves like this, it's better
>> to place the type on the left side of an operation (if you can),
>> since then it'll get a chance to deal with the special casing
>> before the other other argument has to deal with it (that's how
>> mixed type operations work in Python since PEP 208 was implemented).
>> -- 
>> Marc-Andre Lemburg
>> eGenix.com

More information about the egenix-users mailing list