[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> But as I said in my first post, it's simple when you know the amount
> of data that you're going to receive, or when you'll receive data
> until the remote peer closes the connection. But what about receiving
> a message with undetermined length in
Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood <[EMAIL PROTECTED]> writes:
>
> >> Note that appending to a string is almost never a good idea, since it
> >> can result in quadratic allocation.
> >
> > My aim was clear exposition rather than the ultimate performance!
>
> That would
En Mon, 28 Apr 2008 19:29:33 -0300, <[EMAIL PROTECTED]> escribió:
A question regarding cStringIO.StringIO(): is there a way to do get
getvalue() to return all the bytes after the current file position
(not before)? For example
buf = cStringIO.StringIO()
buf.write("foo bar")
buf.seek(3)
buf.getv
On Apr 28, 4:42 am, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood <[EMAIL PROTECTED]> writes:
> > What you are missing is that if the recv ever returns no bytes at all
> > then the other end has closed the connection. So something like this
> > is the correct thing to write :-
>
> >
On Mon, 28 Apr 2008 07:26:13 -0700 (PDT), [EMAIL PROTECTED] wrote:
[snip]
BTW, has anybody used sockets as file-like objects
(client.makefile())? Is it more secure? More efficient?
It's not more (or less) secure. In certain cases, it's significantly less
efficient. It's for simplicity of pr
Nick Craig-Wood <[EMAIL PROTECTED]> writes:
>> Note that appending to a string is almost never a good idea, since it
>> can result in quadratic allocation.
>
> My aim was clear exposition rather than the ultimate performance!
That would normally be fine. My post wasn't supposed to pick
perform
On Apr 28, 4:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I wanted to ask for standard ways to receive data from a socket stream
> > (with socket.socket.recv()). It's simple when you know the amount of
> > data that you're going to receive,
On Mon, 28 Apr 2008 08:30:03 -0500, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
Nick Craig-Wood <[EMAIL PROTECTED]> writes:
> What you are missing is that if the recv ever returns no bytes at all
> then the other end has closed the connection. So someth
Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood <[EMAIL PROTECTED]> writes:
>
> > What you are missing is that if the recv ever returns no bytes at all
> > then the other end has closed the connection. So something like this
> > is the correct thing to write :-
> >
> > data = ""
> >
Nick Craig-Wood <[EMAIL PROTECTED]> writes:
> What you are missing is that if the recv ever returns no bytes at all
> then the other end has closed the connection. So something like this
> is the correct thing to write :-
>
> data = ""
> while True:
> new = client.recv(256)
> if n
Mark Tolonen <[EMAIL PROTECTED]> wrote:
> > So every time I use I want to send some thing, I must use
> >
> > totalsent = 0
> > while sent < len(data):
> >sent = sock.send(data[totalsent:])
> >totalsent += sent
> >
> > instead of a simple sock.send(data)? That's kind of nasty. Also, is it
>
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I wanted to ask for standard ways to receive data from a socket stream
> (with socket.socket.recv()). It's simple when you know the amount of
> data that you're going to receive, or when you'll receive data until
> the remote peer closes the connec
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On Apr 26, 7:25 am, Irmen de Jong <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> Until now, I've been
> doing this little trick:
> data = client.recv(256)
> new = data
> while len(new) == 256:
> new = client.recv(256)
>
On Apr 26, 7:25 am, Irmen de Jong <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Until now, I've been
> > doing this little trick:
>
> > data = client.recv(256)
> > new = data
> > while len(new) == 256:
> > new = client.recv(256)
> > data += new
>
> Are you aware that recv() will
[EMAIL PROTECTED] wrote:
Until now, I've been
doing this little trick:
data = client.recv(256)
new = data
while len(new) == 256:
new = client.recv(256)
data += new
Are you aware that recv() will not always return the amount of bytes asked for?
(send() is similar; it doesn't guarantee t
On Apr 25, 7:39 pm, [EMAIL PROTECTED] wrote:
> I wanted to ask for standard ways to receive data from a socket stream
> (with socket.socket.recv()). It's simple when you know the amount of
> data that you're going to receive, or when you'll receive data until
> the remote peer closes the connection
On Apr 25, 5:52 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I wanted to ask for standard ways to receive data from a socket stream
> > (with socket.socket.recv()). It's simple when you know the amount of
> > data that you're going to receive, or when you'll receiv
[EMAIL PROTECTED] wrote:
I wanted to ask for standard ways to receive data from a socket stream
(with socket.socket.recv()). It's simple when you know the amount of
data that you're going to receive, or when you'll receive data until
the remote peer closes the connection. But I'm not sure which
I wanted to ask for standard ways to receive data from a socket stream
(with socket.socket.recv()). It's simple when you know the amount of
data that you're going to receive, or when you'll receive data until
the remote peer closes the connection. But I'm not sure which is the
best way to receive a
19 matches
Mail list logo
