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. _______________________________________________ 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