[Numpy-discussion] Inconsistent error messages.
Charles R Harris
Sat May 23 18:43:13 CDT 2009
2009/5/23 Stéfan van der Walt <email@example.com>
> Hi Chris and Charles
> 2009/5/23 Charles R Harris <firstname.lastname@example.org>:
> >> Robert thought that should be the default, but I think that means
> >> everyone would be forced to check how many items they got every time
> >> they read, which is too much code and likely to be forgotten and lead to
> >> errors. So I think that an exception should be raised if you ask for n
> >> and get less than n, but that there should be a flag that says something
> >> like "max_items=n", that indicates that you'll take what you get.
> >> I don't like a warning -- it's unconventional to catch those like
> >> exceptions -- if you want n items, and you haven't written code to
> >> handle less than n, you should get an exception. If you have written
> >> code to handle that, that you can use the flag.
> > I don't like the idea of a warning here either. How about adding a
> > 'strict' so that strict=1 means an error is raised if the count isn't
> > reached, and strict=0 means any count is acceptable?
> The reason I much prefer a warning is that you always get data back,
> whether things went wrong or not. If you throw an error, then you
> can't get hold of the last read blocks at all.
> I guess a strict flag is OK, but why, if you've got a warning in
> place? Warnings are easy to catch (and this can be documented in
> fromfile's docstring):
> warnings.simplefilter('error', np.lib.IOWarning)
> In Python 2.6 you can use "catch_warnings":
> with warnings.catch_warnings(True) as w:
> if w: print "Error trying to load file"
Warnings used to warn once and then never again. I once hacked the module to
make it work right but I don't know if it has been officially fixed. Do you
know if it's been fixed?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion