Re: Re: mx.DateTime 3.2.x and numpy

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

Thanks,

   Christian. 



On 3 Jan 2012, at 20:08, "M.-A. Lemburg" <[email protected]> wrote:

> V wrote:
>> M.-A. Lemburg <mal@...> 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
> 
> Professional Python Services directly from the Source  (#1, Jan 03 2012)
>>>> 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/
> 
> 
> _______________________________________________________________________
> eGenix.com User Mailing List                     http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users


_______________________________________________________________________
eGenix.com User Mailing List                     http://www.egenix.com/
https://www.egenix.com/mailman/listinfo/egenix-users