[Numpy-discussion] how can one catch a multiarray.error

Robert Kern robert.kern@gmail....
Tue Jun 2 21:59:15 CDT 2009


On Tue, Jun 2, 2009 at 21:41, Charles R Harris
<charlesr.harris@gmail.com> wrote:
>
>
> On Tue, Jun 2, 2009 at 8:25 PM, Robert Kern <robert.kern@gmail.com> wrote:
>>
>> On Tue, Jun 2, 2009 at 21:20, Charles R Harris
>> <charlesr.harris@gmail.com> wrote:
>> >
>> >
>> > On Mon, Jun 1, 2009 at 8:43 PM, Robert Kern <robert.kern@gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Jun 1, 2009 at 21:37,  <josef.pktd@gmail.com> wrote:
>> >> > how do we catch a multiarray.error in a try except clause?
>> >> >
>> >> > e.g.
>> >> >>>> np.argmin([])
>> >> > Traceback (most recent call last):
>> >> >  File "<pyshell#147>", line 1, in <module>
>> >> >    np.argmin([])
>> >> >  File
>> >> > "C:\Programs\Python25\Lib\site-packages\numpy\core\fromnumeric.py",
>> >> > line 631, in argmin
>> >> >    return _wrapit(a, 'argmin', axis)
>> >> >  File
>> >> > "C:\Programs\Python25\Lib\site-packages\numpy\core\fromnumeric.py",
>> >> > line 37, in _wrapit
>> >> >    result = getattr(asarray(obj),method)(*args, **kwds)
>> >> > multiarray.error: attempt to get argmax/argmin of an empty sequence
>> >>
>> >> try:
>> >>   ...
>> >> except numpy.core.multiarray.error:
>> >>   ...
>> >>
>> >> Unfortunately, that is still a string exception. We should change that.
>> >
>> > I'm fixing these, but doesn't that constitute an abi change? Code that
>> > used
>> > to catch the exceptions won't anymore.
>>
>> If they are catching numpy.core.multiarray.error, then it's not a
>> problem. They never should have been catching "multiarray.error".
>
> Well, I just removed them from  lib/src/_compiled_base.c also. I suppose
> catching string errors from any of numpy's routines could be considered an
> error, but it was the only way folks could do some of these things before.

For multiarray.error and _compiled_base.error, these strings were
exposed in the modules. The one in
numpy.lib.function_base.histogramdd() is a little more problematic,
but the f2py cases aren't. f2py is not used as a library often enough;
I doubt anyone is actually trying to capture those long,
human-readable exception strings.

In any case, we need to do this ASAP. String exceptions are
long-deprecated and are now causing DeprecationWarnings in the
interpreter. Changing exceptions is generally considered an API
change, not an ABI change. We should document it, of course, but I see
no reason not to do it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


More information about the Numpy-discussion mailing list