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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090919/9589902d/attachment.htm>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4