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

[Pascal Chambon]

@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I have currently no plan to work on asynchronous IO like win32's 
readFileEx() etc. (too many troubles for the benefit), however I'd be 
interested by getting non-blocking operations on IPC pipes (I've crossed 
several people in trouble with that, having a process never end on some 
OSes because they couldn't stop threads blocked on pipes).
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 ^^

Else, allright, I'll try to summarize the various points in a PEP-update.

Concerning the "truncate" method however, on second thought I feel we 
might take distance from Posix API for naming, precisely since it's 
anyway too "platform-specific" (windows knows nothing about Posix, and 
even common unix-like systems modify it in a way or another - several 
systems don't zero-fill files when extending them).
When seeing "truncate", in my opinion, most people will think "it's only 
to reduce file size" (for beginners), or will immediately get in mind 
all the tips of posix-like systems (for more experienced developers). 
Shouldn't we, like other cross-platform APIs, use a more unambiguous 
notion, like "setLength" (java) or "resize" (Qt) ? And let the 
filepointer untouched, simply because there are no reasons to move it, 
especially when extending the file (yep, on windows we're forced to move 
the pointer, but it's easy to fix) ?
If it's too late to modify the IO API, too bad, but I don't feel 
comfortable with the "truncate" word. And I don't like the fact that we 
move the filepointer to prevent it from exceeding the file size, whereas 
on the other hand we can seek() anywhere without getting exceptions (and 
so, set the filepointer past the end of file). Having 0 <= filepointer 
<= EOF is OK to me, but then we have to enforce it for all functions, 
not just truncate.

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).
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. This semantic would be perfect for me, and it's already 95% 
here, we would just have to fix some unwelcomed OSErrors exceptions in 
the iomodule. Isn't that worth it ? It'd simplify programmers' job a 
lot, and allow a more subtle treatment of exceptions (if everyone just 
catches Environment errors, without being sure of which subcless is 
actually raised, we miss the point of IOError and OSError).

Regards,
Pascal



>
>
>
> James Y Knight a écrit :
>>
>> On Sep 18, 2009, at 8:58 PM, Antoine Pitrou wrote:
>>> I'm not sure that's true. Various Unix/Linux man pages are readily
>>> available on the Internet, but they regard specific implementations,
>>> which often depart from the spec in one way or another. POSIX specs
>>> themselves don't seem to be easily reachable; you might even have to 
>>> pay
>>> for them.
>>
>>
>> The POSIX specs are quite easily accessible, without payment.
>>
>> I got my quote by doing:
>>     man 3p ftruncate
>>
>> I had previously done:
>>     apt-get install manpages-posix-dev
>> to install the posix manpages. That package contains the POSIX 
>> standard as of 2003. Which is good enough for most uses. It seems to 
>> be available here, if you don't have a debian system:
>>     http://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/
>>
>> There's also a webpage, containing the official POSIX 2008 standard:
>>    http://www.opengroup.org/onlinepubs/9699919799/
>>
>> And to navigate to ftruncate from there, click "System Interfaces" in 
>> the left pane, "System Interfaces" in the bottom pane, and then 
>> "ftruncate" in the bottom pane.
>>
>> James
>> _______________________________________________
>> 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 
>>
>>
>>
>
>