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

[M.-A. Lemburg]

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
server:

http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.tar.gz
http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.zip

Please give it a try.

Thanks,
-- 
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
               http://www.egenix.com/company/contact/

> 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