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

[Charles R Harris]

On Tue, Jun 2, 2009 at 8:59 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Tue, Jun 2, 2009 at 21:41, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Tue, Jun 2, 2009 at 8:25 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
> >>
> >> On Tue, Jun 2, 2009 at 21:20, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >> >
> >> >
> >> > On Mon, Jun 1, 2009 at 8:43 PM, Robert Kern <robert.kern at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Mon, Jun 1, 2009 at 21:37,  <josef.pktd at 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.
>

OK. I left the strings exposed in the modules with a fixme notes. Do you
think they should be removed while we are at it?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090602/2767bff4/attachment.html>