[Python-Dev] Fuzziness in io module specs (original) (raw)

Daniel Stutzbach daniel at stutzbachenterprises.com
Fri Sep 18 22:15:28 CEST 2009

On Fri, Sep 18, 2009 at 2:17 PM, Pascal Chambon <chambon.pascal at gmail.com>wrote:

- it is unclear what truncate() methods do with the file pointer, and even if the current implementation simply moves it to the truncation point, it's very contrary to the standard way of doing under unix, where the file pointer is normally left unchanged. Shouldn't we specify that the file pointer remains unmoved, and fix the fileio module accordingly ?

+1 on having consistent, documented behavior (regardless of what that behavior is :) ).

- exceptions are not always specified, and even if most of them are IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if we try to wrap a wrong file descriptor when instanciating a new FileIO). This might lead to bad program crashes if some people don't "refuse the temptation to guess" and only get prepared to catch IOErrors

I'd wager that you may also get a WindowsError in some cases, on Windows systems. Part of the reason for having several different, but similar, exceptions is that they may contain operating system specific error codes and the type of exception helps the programmer figure out how to interpret those codes. I'm not really clear on when IOError is preferred over OSError, but I know that WindowsError necessarily uses a completely different error numbering system.

The careful programmer should catch EnvironmentError, which is the base class of all of these different kinds of related errors.

+1 on documenting that the methods may raise an EnvironmentError.

- the doc sometimes says that when we receive an empty string from a read() operation, without exceptions, it means the file is empty. However, with the current implementation, if we call file.read(0), we simply receive "", even though it doesn't mean that we're at EOF. Shouldn't we avoid this (rare, I admit) ambiguity on the return value, by preventing read(0) ? Or at least, note in the doc that (we receive an empty string) <-> (the file is at EOF OR we called read with 0 as parameter) ?

Some programs may rely on read(0) and the behavior matches the behavior of POSIX, so I'm -1 on changing the behavior. +1 on documenting the exception to the rule.

Are there some arguments that I don't know, which lead to this or that particular implementation choice ?

The original I/O PEP and some of the code was put together during a sprint at PyCon 2007. Our primary goal was to get a decent first cut of the new I/O system put together quickly. For nitty-gritty details and corner-cases like these, there's a good chance that the current undocumented behavior is simply an accident of implementation.

-- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090918/4634ade5/attachment.htm>

More information about the Python-Dev mailing list