Marko Rauhamaa :
> Python's sockets and pipes don't have write methods.
Actually, that's mistaken as well. The sys.std* handles and pipes
returned by subprocess are accessed using file.write() and thus may
return partial writes.
That brings up another point: Python3's file.write() returns the nu
Nobody :
> Asynchronous I/O in the sense of select(), poll(), O_NONBLOCK etc is
> meant for situations where delays could be indefinite, e.g. network
> connections or terminals. For "short" delays (i.e. disc access),
> there's not much point having a mechanism so that you can avoid
> blocking whil
On Mon, 27 Oct 2014 17:14:58 +0200, Marko Rauhamaa wrote:
> In POSIX, a write(2) system call on file blocks until all bytes have been
> passed on to the file system. The only exception (no pun intended) I know
> is the reception of a signal.
Writing to a file (or block device) will return a short
Grant Edwards :
> If you really want to make sure that all bytes get written, you _must_
> put all write() calls in a loop that checks the return value and keeps
> re-writing any unwritten data.
>
> And to answer your next question: yes, Unix application programmers
> have been complaining about t
On 2014-10-27, Steven D'Aprano wrote:
> Roy Smith wrote:
>
>>> Yes and no. If something goes wrong in a .write() method,
>>> is not Python supposed to raise an error? (!)
>>
>> Define "wrong". It is not an error for a write() call to consume fewer
>> bytes than were requested.
>
> It's not? I'
On 2014-10-25, Wolfgang Maier wrote:
> It may be rare to use an expression both for its side-effects and its
> return value,
It's actually quite common.
For example:
f = open("filename")
d = f.readline()
In both of those lines, the side effects and return values are equally
vital. The
In article <544e2cf2$0$13009$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> Roy Smith wrote:
>
> >> Yes and no. If something goes wrong in a .write() method,
> >> is not Python supposed to raise an error? (!)
> >
> > Define "wrong". It is not an error for a write() call to cons
On Mon, Oct 27, 2014 at 10:30 PM, Steven D'Aprano
wrote:
> Roy Smith wrote:
>
>>> Yes and no. If something goes wrong in a .write() method,
>>> is not Python supposed to raise an error? (!)
>>
>> Define "wrong". It is not an error for a write() call to consume fewer
>> bytes than were requested.
Roy Smith wrote:
>> Yes and no. If something goes wrong in a .write() method,
>> is not Python supposed to raise an error? (!)
>
> Define "wrong". It is not an error for a write() call to consume fewer
> bytes than were requested.
It's not? I'm asking a genuine question here, not a rhetorical
In article <683c84d8-d916-4b63-b4b2-92cd2763e...@googlegroups.com>,
wxjmfa...@gmail.com wrote:
> Le dimanche 26 octobre 2014 14:41:43 UTC+1, Dan Sommers a écrit :
> > On Sun, 26 Oct 2014 00:45:49 -0700, wxjmfauth wrote:
> >
> > > Ditto for .write(). Why should it return "something" ?
> > >
> >
wxjmfa...@gmail.com:
> Yes and no. If something goes wrong in a .write() method,
> is not Python supposed to raise an error? (!)
We have multiple cases:
1. write succeeds with all of the given bytes
2. write succeeds with some but not all of the given bytes
3. write cannot at the moment wri
On Sunday, October 26, 2014 7:11:43 PM UTC+5:30, Dan Sommers wrote:
> At one time, on a huge project, millions of lines of C and assembly
> code, we had a local guideline *not* to write void functions. The idea
> was to return something that might be useful later, even if it seemed
> unlikely now
On Sun, 26 Oct 2014 00:45:49 -0700, wxjmfauth wrote:
> Ditto for .write(). Why should it return "something" ?
>
with open('z.txt', 'w') as f:
> ... f.write('abc')
> ...
> 3
OTOH, why shouldn't it return something? In this case, it returns the
length of the string written. This va
On 10/25/2014 6:22 PM, Dan Sommers wrote:
On Sat, 25 Oct 2014 23:41:52 +0200, Wolfgang Maier wrote:
... It may be rare to use an expression both for its side-effects and
its return value ...
A lot of concurrency-related operations work that way. In the old days,
it was CPU-level Test and Set
On Sat, 25 Oct 2014 23:41:52 +0200, Wolfgang Maier wrote:
> ... It may be rare to use an expression both for its side-effects and
> its return value ...
A lot of concurrency-related operations work that way. In the old days,
it was CPU-level Test and Set (or Compare and Set) instructions. These
On 25.10.2014 19:27, Rustom Mody wrote:
Moved from other (Seymore's) thread where this is perhaps not relevant
On Saturday, October 25, 2014 1:15:09 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote:
On Sat, Oct 25
Moved from other (Seymore's) thread where this is perhaps not relevant
On Saturday, October 25, 2014 1:15:09 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
>
> > On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote:
> >> On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody
17 matches
Mail list logo
