Good example with "os.write(f.fileno(), 'blah')" - and you obtain the
same error if you try to open an io.FileIo by providing a file
descriptor instead of a file name as first argument. This would really
deserve an unification.
Actually, since Windows Error Codes concern any possible error (IO, file
permissions, memory problems...), I thought the best would be to convert
them to the most appropriate python standard exception, only defaulting
to WindowsError (i.e, OSError's hierarchy) when no other exception type
matches. So at the moment, I use a decorator to automatically convert
all errors on stream operations into IOErrors. Error codes are not the
same as unix ones indeed, but I don't know if it's really important
(imo, most people just want to know if the operation was successful, I
don't know if many developers scan error codes to act accordingly). For
IOError types that really matter (eg. file already locked, buffer full),
the easiest is actually to use subclasses of IOError (the io module
already does that, even though I'll maybe have to create new exceptions
for errors like "file already exists" or "file already locked by another
process")
Regards,
Pascal
Daniel Stutzbach a écrit :
On Sat, Sep 19, 2009 at 2:46 AM, Pascal Chambon
<chambon.pas...@gmail.com <mailto: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/firephoenix%40wanadoo.fr
_______________________________________________
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
