Pascal Chambon wrote:
Found in current io PEP :
Q: Do we want to mandate in the specification that switching between
reading and writing on a read-write object implies a .flush()? Or is
that an implementation convenience that users should not rely on?
-> it seems that the only important matter is : file pointer positions
and bytes/characters read should always be the ones that the user
expects, as if there
were no buffering. So flushing or not may stay a non-mandatory
behaviour, as long as the buffered streams ensures this data integrity.
Eg. If a user opens a file in r/w mode, writes two bytes in it (which
stay buffered), and then reads 2 bytes, the two bytes read should be
those on range [2:4] of course, even though the file pointer would,
due to python buffering, still be at index 0.
Q from me : What happens in read/write text files, when overwriting a
three-bytes character with a single-byte character ? Or at the
contrary, when a single chinese character overrides 3 ASCII characters
in an UTF8 file ? Is there any system designed to avoid this data
corruption ? Or should TextIO classes forbid read+write streams ?
IO Exceptions :
Currently, the situation is kind of fuzzy around EnvironmentError
subclasses.
* OSError represents errors notified by the OS via errno.h error codes
(as mirrored in the python "errno" module).
errno.h errors (less than 125 error codes) seem to represent the whole
of *nix system errors. However, Windows has many more system errors
(15000+). So windows errors, when they can't be mapped to one of the
errno errors are raises as "WindowsError" instances (a subclass of
OSError), with the special attribute "winerror" indicating that win32
error code.
* IOError are "errors raised because of I/O problems", but they use
errno codes, like OSError.
Thus, at the moment IOErrors rather have the semantic of "particular
case of OSError", and it's kind of confusing to have them remain in
their own separate tree... Furthermore, OSErrors are often used where
IOErrors would perfectly fit, eg. in low level I/O functions of the OS
module.
Since OSErrors and IOErrors are slightly mixed up when we deal with IO
operations, maybe the easiest way to make it clearer would be to push
to their limits already existing designs.
- the os module should only raise OSErrors, whatever the os operation
involved (maybe it's already the case in CPython, isn't it ?)
- the io module should only raise IOErrors and its subclasses, so that
davs can easily take measures depending on the cause of the io failure
(except 1 OSError exception, it's already the case in _fileio)
- other modules refering to i/o might maybe keep their current (fuzzy)
behaviour, since they're more platform specific, and should in the end
be replaced by a crossplatform solution (at least I'd love it to happen)
Until there, there would be no real benefits for the user, compared to
catching EnvironmentErrors as most probably do. But the sweet thing
would be to offer a concise but meaningfull IOError hierarchy, so that
we can easily handle most specific errors gracefully (having a disk
full is not the same level of gravity as simply having another process
locking your target file).
Here is a very rough beginning of IOError hierarchy. I'd liek to have
people's opinion on the relevance of these, as well as on what other
exceptions should be distinguished from basic IOErrors.
IOError
+-InvalidStreamError (eg. we try to write on a stream opened in
readonly mode)
+-LockingError
+-PermissionError (mostly *nix chmod stuffs)
+-FileNotFoundError
+-DiskFullError
+-MaxFileSizeError (maybe hard to implement, happens when we exceed
4Gb on fat32 and stuffs...)
+-InvalidFileNameError (filepath max lengths, or "? / : " characters
in a windows file name...)
Personally I'd love to see a richer set of exceptions for IO errors, so
long as they can be implemented for all supported platforms and no
information (err number from the os) is lost.
I've been implementing a fake 'file' type [1] for Silverlight which does
IO operations using local browser storage. The use case is for an online
Python tutorial running in the browser [2]. Whilst implementing the
exception behaviour (writing to a file open in read mode, etc) I
considered improving the exception messages as they are very poor - but
decided that being similar to CPython was more important.
Michael
[1]
http://code.google.com/p/trypython/source/browse/trunk/trypython/app/storage.py
and
http://code.google.com/p/trypython/source/browse/trunk/trypython/app/tests/test_storage.py
[2] http://www.trypython.org/
Regards,
Pascal
_______________________________________________
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/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
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
