On Fri, Sep 18, 2009 at 2:17 PM, Pascal Chambon <chambon.pas...@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>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
