Antoine Pitrou a écrit :
Hello,
Pascal Chambon <pythoniks <at> gmail.com> writes:
@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I was talking about the existing support for non-blocking IO in the FileIO class
(look up EAGAIN in fileio.c), as well as in the Buffered* objects.
Allright, I'll check that EAGAIN stuff, that I hadn't even noticed :)
And I don't like the fact that we
move the filepointer to prevent it from exceeding the file size,
I don't see what you mean:
Well the sample code you showed is not shocking, but I'd like to have a
coherency the with file.seek(), because if truncate() prevents
out-of-bound file pointer, other methods should do the same as well (and
raise IOError when seeking out of file bounds).
I had the feeling that IOErrors were for operations on file streams
(opening, writing/reading, closing...), whereas OSErrors were for
manipulations on filesystems (renaming, linking, stating...) and
processes.
Ok, but the distinction is certainly fuzzy in many cases. I have no problem with
trying to change the corner cases you mention, though.
The case which could be problematic there is the file opening, because
it can involve problems at all levels of the OS (filesystem not
existing, permission problems, file locking...), so we should keep it in
the "EnvironmentError" area.
But as soon as a file is open, I guess only IOErrors can be involved (no
space left, range locked etc), so enforcing all this to raise IOError
would be OK I think.
_______________________________________________
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
