On Sat, Sep 19, 2009 at 2:46 AM, Pascal Chambon <chambon.pas...@gmail.com>wrote:
> This reimplementation is actually necessary to get file locking, because
> advanced win32 operations only work on real file handles, not the handles
> that are underlying the C API layer. Furthermore, some interesting features
> (like O_EXCL | O_CREAT) are not possible with the current io
> implementations. So well, reimplementation required ^^
>
> Concerning exceptions, which one is raised is not so important to me, as
> long as it's well documented and not tricky (eg. WindowsErrors are OK to me,
> because they subclass OSError, so most cross-platform programs wont even
> have to know about them).
>
If you use real Windows file handles (instead of the POSIX-ish Windows API),
won't you need to return WindowsErrors?
> 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.
>
If that were documented and a firm rule, that would certainly be great.
It's not too hard to find counterexamples in the current codebase. Also,
I'm not sure how one could avoid needing to raise WindowsError in some
cases.
Maybe someone with more knowledge of the history of IOError vs. OSError
could chime in.
Python 2.6:
>>> os.write(f.fileno(), 'blah')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
>>> f.write('blah')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
_______________________________________________
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
