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

[Christian Marquardt]

Thanks!

That worked well - our application works absolutely fine again.

   Christian.


----- "M.-A. Lemburg" <mal at egenix.com> wrote:

> 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

-- 
Dr. Christian Marquardt     Email:  christian at marquardt.sc
Im Hausstück 16             Tel.:   +49 (0) 6257 503 85 78
64665 Alsbach-Hähnlein      Mobile: +49 (0) 179 290 84 74
Germany