[Python-Dev] Fuzziness in io module specs

[Antoine Pitrou]

Le Fri, 18 Sep 2009 21:17:29 +0200, Pascal Chambon a écrit :


Hello,

First, thanks for experimenting with this.
(as a sidenote, we lack real-world testing of non-blocking features, 
perhaps you want to take a look)

> I'm currently working on a reimplementation of io.FileIO, which would 
> allow cross-platform file range locking and all kinds of other safety 
> features ;

Hmm, do you *have* to reimplement it in order to add these new features, 
or is it just a personal preference?

> - 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 ?

Well, first Python and its IO library are cross-platform, so the 
behaviour is not always identical to POSIX behaviour, especially where 
Windows and Unix have different specs.

Second, now that 3.1 is in the wild, we should be reluctant to change the
behaviour just to make it more conformant to what POSIX people can 
expect. What might be convincing would be an actual use case where POSIX-
like behaviour would be significantly more useful than the current on.

> - 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 is not different than with 2.x here. If you want to trap both 
OSError and IOError, use EnvironmentError (which is the common base class 
for both).

I agree it is slightly annoying and not well-defined, however. Also, 
Python can hardly determine by itself whether an error is caused by IO 
problems or an OS-level malfunction, so the distinction is a bit 
fallacious.

> 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) ?

Well, if you are asking for 0 bytes, it returns 0 bytes. It's not that
ambiguous, and it helps avoid special-casing the 0 case :)

> So wouldn't it be a godo idea to write some kind of mini-pep, just to 
> fix the corner cases of the current IO documentation ?

Improvements, either to the docs or to the implementation, are always 
welcome. I think you already know where to post them!

Regards

Antoine.