[Python-Dev] POSIX [Fuzziness in io module specs]

[Pascal Chambon]

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.pascal at gmail.com <mailto:chambon.pascal at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/firephoenix%40wanadoo.fr
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090919/e4f09df6/attachment.htm>