[egenix-users] Re: mx.DateTime 3.2.x and numpy
christian at marquardt.sc
Thu Jan 5 01:16:46 CET 2012
That worked well - our application works absolutely fine again.
----- "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
> Please give it a try.
> Marc-Andre Lemburg
> eGenix.com Professional Python Services directly from the Source
> >>> Python/Zope Consulting and Support ...
> >>> mxODBC.Zope.Database.Adapter ...
> >>> mxODBC, mxDateTime, mxTextTools ...
> ::: 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
> >>>> 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
> >> operation. This solves the problem with numpy and should also
> >> 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
> >> --
> >> 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
More information about the egenix-users