Pascal Chambon wrote: > Hello > > Below is a corrected version of the PEP update, adding the start/end > indexes proposition and fixing functions signatures. Does anyone > disagree with these specifications ? Or can we consider it as a target > for the next versions of the io module ? > I would have no problem to implement this behaviour in my own pure > python FileIO system, however if someone is willing to patch the _fileio > implementation, it'd save a lot of time - I most probably won't have the > means to setup a C compilation environment under windows and linux, and > properly update/test this, before January (when I get freelance...). > > I launch another thread on other to-be-discussed IO points B-) > > Regards, > Pascal > > ================ PEP UPDATE for new I/O system - v2 =========== > > **Truncate and file pointer semantics** > > Rationale : > > The current implementation of truncate() always move the file pointer to > the new end of file. > > This behaviour is interesting for compatibility, if the file has been > reduced and the file pointer is now past its end, since some platforms > might require 0 <= filepointer <= filesize. > > However, there are several arguments against this semantic: > > * Most common standards (posix, win32…) allow the file pointer to be > past the end of file, and define the behaviour of other stream > methods in this case > * In many cases, moving the filepointer when truncating has no > reasons to happen (if we’re extending the file, or reducing it > without going beneath the file pointer) > * Making 0 <= filepointer <= filesize a global rule of the python IO > module doesn’t seems possible, since it would require > modifications of the semantic of other methods (eg. seek() should > raise exceptions or silently disobey when asked to move the > filepointer past the end of file), and lead to incoherent > situations when concurrently accessing files without locking (what > if another process truncates to 0 bytes the file you’re writing ?) > > So here is the proposed semantic, which matches established conventions: > > *IOBase.truncate(n: int = None) -> int* > > Resizes the file to the size specified by the positive integer n, or by > the current filepointer position if n is None. > > The file must be opened with write permissions. > > If the file was previously larger than size, the extra data is discarded. > If the file was previously shorter than size, its size is increased, and > the extended area appears as if it were zero-filled. > Instead of "than size", perhaps "than n". > In any case, the file pointer is left unchanged, and may point beyond > the end of file. > > Note: trying to read past the end of file returns an empty string, and > trying to write past the end of file extends it by zero-ing the gap. On > rare platforms which don't support file pointers to be beyond the end of > file, all these behaviours shall be faked thanks to internal storage of > the "wanted" file pointer position (silently extending the file, if > necessary, when a write operation occurs). > > > > *Propositions of doc update* > > *RawIOBase*.read(n: int) -> bytes > > Read up to n bytes from the object and return them. Fewer than n bytes > may be returned if the operating system call returns fewer than n bytes. > If 0 bytes are returned, and n was not 0, this indicates end of file. If > the object is in non-blocking mode and no bytes are available, the call > returns None. > > > *RawIOBase*.readinto(b: bytearray, [start: int = None], [end: int = > None]) -> int > > start and end are used as slice indexes, so that the bytearray taken > into account is actually range = b[start:end] (or b[start:], b[:end] or > b[:], depending on the arguments which are not None). > > Read up to len(range) bytes from the object and store them in b, returning > the number of bytes read. Like .read, fewer than len(range) bytes may be > read, and 0 indicates end of file if len(range) is not 0. > None is returned if a non-blocking object has no bytes available. The > length of b is never changed. > Should an exception be raised if start and/or end are out of range?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4