Steven D'Aprano wrote:
Using "truncate" to mean "increase in size" makes about as much sense as
having a list method called "remove" used to insert items. I can't
imagine what the committee who approved this were thinking.
I expect the reason is historical. Some time back in the
early days of
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
On Sat, 19 Sep 2009 06:08:23 am James Y Knight wrote:
> On Sep 18, 2009, at 3:55 PM, MRAB wrote:
> > I think that this should be an invariant:
> >
> >0 <= file pointer <= file size
> >
> > so the file pointer might sometimes have to be moved.
> >
> > As for the question of whether 'truncate' sh
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.
qwavel wrote:
> What about this bug:
> http://bugs.python.org/issue3890
> It appears to me that the SSL module is broken in the 2.6.x line on all
> platforms in one of its most common uses (non-blocking). It also seems that
> the problem and solution are well understood, so the solution would ma
Barry Warsaw wrote:
>
> On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
>
>> The IDLE issue is IMHO a release blocker, as is issue 6851.
>
> So that leaves 4 release blockers for 2.6.3.
>
What about this bug:
http://bugs.python.org/issue3890
It appears to me that the SSL module is broken
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
Cameron Simpson wrote:
On 18Sep2009 07:48, Nick Coghlan wrote:
| Eric Smith wrote:
| > Peter Moody wrote:
| >> indexing is plenty efficient, but the problem is that these names for
| >> these attributes are common to the point of causing confusion if
| >> they're omitted.
| >
| > After thinking
On 18Sep2009 07:48, Nick Coghlan wrote:
| Eric Smith wrote:
| > Peter Moody wrote:
| >> indexing is plenty efficient, but the problem is that these names for
| >> these attributes are common to the point of causing confusion if
| >> they're omitted.
| >
| > After thinking about it some more, I'm
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
2009/9/18 Peter Moody :
> On Thu, Sep 17, 2009 at 6:17 PM, Andrew McNamara
> wrote:
>>>off to patch the pep and implement some of the non controversial changes.
>>
>> It might be a good idea to add some use-cases to the PEP.
>
> There are several use-cases in the PEP already.
>
> The problem is, f
@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,
21 matches
Mail list logo
