[Numpy-discussion] Inconsistent error messages.
Charles R Harris
charlesr.harris at gmail.com
Sat May 23 16:27:12 EDT 2009
On Sat, May 23, 2009 at 2:02 PM, Christopher Barker
<Chris.Barker at noaa.gov>wrote:
> Stéfan van der Walt wrote:
> > 2009/5/23 Charles R Harris <charlesr.harris at gmail.com>:
> >> In [9]: fromfile("empty.dat", count=10)
>
> > Instead of throwing errors in these scenarios, we could just return
> > the elements read and raise a warning? This is consistent with most
> > other file APIs I know and allows you to read blocks of data until the
> > data runs out.
>
> This was just discussed a week or two ago (look for messaged by me and
> Robert Kern)
>
> fromfile needs some attention in general, but I think Robert an I (the
> only two that I know were paying attention to that discussion) agreed
> that there should be an API that says:
>
> read up to n items from the file
>
> 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 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?
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090523/4f398dcf/attachment.html>
More information about the NumPy-Discussion
mailing list