On Tue, Jun 2, 2009 at 8:25 PM, Robert Kern <robert.k...@gmail.com> wrote:
> On Tue, Jun 2, 2009 at 21:20, Charles R Harris > <charlesr.har...@gmail.com> wrote: > > > > > > On Mon, Jun 1, 2009 at 8:43 PM, Robert Kern <robert.k...@gmail.com> > wrote: > >> > >> On Mon, Jun 1, 2009 at 21:37, <josef.p...@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. Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion