What we could do with is better platform-independent
ways of distinguishing particular error conditions,
such as file not found, out of space, etc., either
using subclasses of IOError or mapping error codes
to a set of platform-independent ones.
Well, mapping all errors (including C ones and
Nick Coghlan wrote:
For example, a file not existing, a file being locked by another
process, and the user not having write permissions to the file are
problems that demand very different responses from the user.
You can display an error-specific message without having
to inspect the error cod
Pascal Chambon wrote:
And let the
filepointer untouched, simply because there are no reasons to move it,
On some systems it may not be possible for the file pointer to
be positioned past the end of the file (I think Classic MacOS
was like that).
I had the feeling that IOErrors were for opera
On Sat, 19 Sep 2009 08:31:15 pm Pascal Chambon wrote:
> Error codes are not the
> same as unix ones indeed, but I don't know if it's really important
> (imo, most people just want to know if the operation was successful,
> I don't know if many developers scan error codes to act accordingly).
I do.
Antoine Pitrou a écrit :
Hello,
Pascal Chambon gmail.com> writes:
@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I was talking about the existing support for non-blocking IO in the FileIO class
(look up EAGAIN in fileio.c), as well as in the Buffered* obj
Hello,
Pascal Chambon gmail.com> writes:
> @pitrou: non-blocking IO in python ? which ones are you thinking about ?
I was talking about the existing support for non-blocking IO in the FileIO class
(look up EAGAIN in fileio.c), as well as in the Buffered* objects.
> If it's too late to modify t
Pascal Chambon wrote:
> (imo, most people just want to know if the operation was successful, I
> don't know if many developers scan error codes to act accordingly).
And as a user of applications written by those developers, it is a
practice I detest with a passion. Debugging environmental problems
On Sat, 19 Sep 2009 at 12:31, Pascal Chambon wrote:
stream operations into IOErrors. Error codes are not the same as unix ones
indeed, but I don't know if it's really important (imo, most people just want
to know if the operation was successful, I don't know if many developers scan
error codes
>> I
>> believe POSIX documentation to be more accessible to a variety of Python
>> developers than other system's, and it's better documented: rationales
>> are included, history is available, etc.
>
> I'm not sure that's true. Various Unix/Linux man pages are readily
> available on the Internet
@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 peopl
On Sat, Sep 19, 2009 at 5:31 AM, Pascal Chambon wrote:
> Actually, since Windows Error Codes concern any possible error (IO, file
> permissions, memory problems...), I thought the best would be to convert
> them to the most appropriate python standard exception, only defaulting to
> WindowsError
Good example with "os.write(f.fileno(), 'blah')" - and you obtain the
same error if you try to open an io.FileIo by providing a file
descriptor instead of a file name as first argument. This would really
deserve an unification.
Actually, since Windows Error Codes concern any possible error (IO
On Sat, Sep 19, 2009 at 2:46 AM, Pascal Chambon wrote:
> 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
@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 peopl
Antoine Pitrou writes:
> I don't believe that POSIX compliance is a sufficient argument to ask
> someone to shut up in the discussion of a cross-platform API. Which is
> more or less what James' answer was trying to do.
No, as I read it, James said, "when there's precedent, even a
standard,
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 reachab
Le Sat, 19 Sep 2009 09:19:53 +0900, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
> > James Y Knight fuhm.net> writes:
> > >
> > > Why are you just making things up? There is a *vast* amount of
> > > precedent for how file operations should work. Python should follow
> > > that prec
Antoine Pitrou writes:
> James Y Knight fuhm.net> writes:
> >
> > Why are you just making things up? There is a *vast* amount of
> > precedent for how file operations should work. Python should follow
> > that precedent and do like POSIX unless there's a compelling reason
> > not to.
James Y Knight fuhm.net> writes:
>
> Why are you just making things up? There is a *vast* amount of
> precedent for how file operations should work. Python should follow
> that precedent and do like POSIX unless there's a compelling reason
> not to.
Actually, Python is cross-platform and t
19 matches
Mail list logo