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

M.-A. Lemburg mal at egenix.com
Tue Jan 3 20:08:25 CET 2012


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

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/



More information about the egenix-users mailing list