Hello everyone
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 ; however I'm slightly stuck due to some specification
fuzziness in the IO docs.
CF http://bugs.python.org/issue6939
The main points that annoy me at the moment :
- 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 ?
- 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
- 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) ?
Are there some arguments that I don't know, which lead to this or that
particular implementation choice ?
I'd strongly advocate very detailled specifications, letting no room for
cross-platform subtilities (that's also a strong goal of my
reimplemntation), since that new IO system (which saved me a lot of
coding time, by the way) should become the base of many programs.
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 ? I might handle
it, if no more-knowledgeable people feels like it.
Regards,
Pascal
_______________________________________________
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
