@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@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
