Michael Foord wrote:
You said that having an exception hierarchy was impossible because the
only information we have is the error number.
No, I said that having an exception hierarchy wouldn't
help you to sort out the different meanings of a single
error code.
If you have some *other* way of
Greg Ewing wrote:
Michael Foord wrote:
Well, the file type knows what mode it is opened in so catching these
errors is really not difficult at all.
Yes, in this particular case it could do some checking of
its own before making the system call. But this still has
nothing to do with the except
Michael Foord wrote:
Well, the file type knows what mode it is opened in so catching these
errors is really not difficult at all.
Yes, in this particular case it could do some checking of
its own before making the system call. But this still has
nothing to do with the exception hierarchy.
--
Antoine Pitrou wrote:
> Le Mon, 28 Sep 2009 06:41:17 +1000, Nick Coghlan a écrit :
>> Michael's response cut to the heart of the issue though - a richer IO
>> exception hierarchy can make life interesting for compatibility purposes
>> (especially when creating "file-like" interfaces to non-file obj
Greg Ewing wrote:
Michael Foord wrote:
Some of the error messages are truly awful though as things stand,
especially for someone new to Python. Try to read from a file handle
opened in read mode for example: IOError: [Errno 9] Bad file descriptor
Subdividing the IOError exception won't help
+-InvalidFileNameError (filepath max lengths, or "? / : " characters
in a windows file name...)
This might be a bit too precise. Unix just has EINVAL, which
covers any kind of invalid parameter, not just file names.
Allright thanks, an InvalidParameter (or similar) exception should do it
Michael Foord wrote:
Some of the error messages are truly awful though as things stand,
especially for someone new to Python. Try to read from a file handle
opened in read mode for example: IOError: [Errno 9] Bad file descriptor
Subdividing the IOError exception won't help with
that, because
Le Mon, 28 Sep 2009 06:41:17 +1000, Nick Coghlan a écrit :
>
> Not as such - a big exception hierarchy rewrite was rejected, but
> nothing specifically limited to the IO exceptions.
>
> Michael's response cut to the heart of the issue though - a richer IO
> exception hierarchy can make life inter
Nick Coghlan wrote:
Antoine Pitrou wrote:
This deserves its own PEP IMO, although I'm not sure it would be accepted
(ISTR the idea of a detailed IO exception hierarchy was already refused
in the past).
Not as such - a big exception hierarchy rewrite was rejected, but
nothing specifica
Antoine Pitrou wrote:
> This deserves its own PEP IMO, although I'm not sure it would be accepted
> (ISTR the idea of a detailed IO exception hierarchy was already refused
> in the past).
Not as such - a big exception hierarchy rewrite was rejected, but
nothing specifically limited to the IO exc
On Sep 27, 2009, at 4:20 AM, Pascal Chambon wrote:
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.
MRAB mrabarnett.plus.com> writes:
>
> If the characters are always the same number of bytes) then overwriting
> could be possible; that would, however, make the behaviour more
> complicated (sometimes you can, sometimes you can't), so it's probably
> just simpler to forbid read+write text streams
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
Le Sun, 27 Sep 2009 10:20:23 +0200, Pascal Chambon a écrit :
> Q: Do we want to mandate in the specification that switching between
> reading and writing on a read-write object implies a .flush()?
It doesn't and shouldn't be mandated in the specification, IMO. An
implementation should be free to
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
Pascal Chambon wrote:
-> 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.
That sounds right to me.
Q from me : What happens in read/write text files, when overwriting
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 posit
17 matches
Mail list logo
