[Python-Dev] Fuzziness in io module specs

[Daniel Stutzbach]

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>