Pascal Chambon <chambon.pas...@gmail.com> added the comment:
Well, I guess it deserve discussion on the pydev mailing lits, that's
imo a rather important point, to be documented precisely.
Concerning the padding, I guess the semantic doesn't change between the
io module and the old file type, i.e :
file.truncate([size])¶
Truncate the file’s size. If the optional size argument is present,
the file is truncated to (at most) that size. The size defaults to the
current position. The current file position is not changed. Note that if
a specified size exceeds the file’s current size, the result is
platform-dependent: possibilities include that the file may remain
unchanged, increase to the specified size as if zero-filled, or increase
to the specified size with undefined new content. Availability: Windows,
many Unix variants.
Having platform-dependent semantics for a so important type is anyway
dangerous, I feel. The io module should be rock-solid, with very deeply
documented semantics, and implementations that force platforms to
conform to these specifications. Eg. I've noticed that all io.FileIO
methods raised IOErrors in case of problem, except in one case (wrapping
a bad file decsriptor) where it's OSError - that little thing might make
big programs crash in an ugly way, if they only caught IOError.
I'm currently working on a cross-platform (linux, mac, windows at least)
FileIO type, with very strict semantics and extended abilities (file
range shared and exclusive locking, with timeouts) ; even though it'll
initially be slower than _fileio (most of it is in pure python), maybe
it might solve most of these io module problems. I'll keep people informed.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
