[Numpy-discussion] Inconsistent error messages.

[Christopher Barker]

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

exactly.

> 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:
>     np.fromfile('x')

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!

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

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