[Numpy-discussion] Inconsistent error messages.
Tue May 26 00:23:14 CDT 2009
Charles R Harris wrote:
> I don't like the idea of a warning here either. How about adding a
> keyword 'strict' so that strict=1 means an error is raised if the count
> isn't reached, and strict=0 means any count is acceptable?
I'd prefer a more meaningful name than "strict" -- you'd have absolutely
no idea what that meant without reading the docs -- maybe
allow_partial_read? (and please, True and False, rather than 1 or 0) I
also STRONGLY prefer that it be default to raise an exception.
I am convinced that a Warning is NOT the right way to handle this. While
it does appear that a warning can be caught if need be (though it's not
totally clear whether the "raise this every time" option works..), it's
not default behavior, and it's not a well know feature. This discussion
makes that absolutely clear.
I may or may not be representative, but I am no python newbie, and I had
no idea before this discussion how one would handle a warning in this case.
As far as I can see, there are only two possibilities:
1) The writer of the code has anticipated that not all the items
requested might be read in, and has written the code to handle that
case. In this case s/he would use strict=False
2) The code does not handle that case, either because writer of the code
did not anticipate that it would ever happen, or because it really would
be a failure. In that case, an Exception is the only correct result --
anything else is inviting hidden bugs.
I completely fail to see the logic on a warning here, and I have never
seen warnings used it this way. I also don't see what the objection to
an exception is if there is a flag that can turn it off.
Stéfan van der Walt wrote:
> 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):
so are exceptions -- and even more so, so are flags.
> warnings.simplefilter('error', np.lib.IOWarning)
a pain, and no well known.
> In Python 2.6 you can use "catch_warnings":
much better, but still not used much.
The key issue here is that a lot of folks WILL NOT HAVE THOUGHT about
what they want to do if not all the items are read -- in that case, it
is an error. If they have thought about it, they can turn off the strict
(or whatever) flag.
Stéfan van der Walt wrote:
> Warnings are a great way of telling the user that a non-fatal problem
> cropped up.
but this is only a non-fatal problem if the code has planned for it --
if not it is likely to be fatal.
> Maybe we should provide tools in NumPy to handle warnings more easily?
> Something like
> with no_warnings:
nice, but only if this becomes a standard, common paradigm that is
widely known -- IT IS NOT NOW.
It would be interesting to survey how warnings are used in python these
days -- most of the ones I've seen are deprecation warnings -- that's
the kind of thing they should be used for -- you want people to know,
but it doesn't indicate anything even possibly fatal at this point.
Sorry to be so strong in my opinion here, but I know this is something
I'm going to screw up given the chance. I really want that exception!
Christopher Barker, Ph.D.
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
More information about the Numpy-discussion