Lucas P Melo wrote:
Am I understanding this correctly:
* The blocking version would not do any raw reads.
No, the blocking version would keep doing raw reads
until the buffer contains enough bytes.
--
Greg
___
Python-Dev mailing list
Greg Ewing wrote:
That's exactly why I think the blocking version should
keep reading until the requested number of bytes is
available (or the buffer is full or EOF occurs).
Do you mean that the blocking version should keep waiting for new bytes
until they show up?
This would not be acceptable,
Greg Ewing wrote:
Even if you don't mention it explicitly, its
existence shows through in the fact that there
is an arbitrary limit on the amount you can
peek ahead, and that limit needs to be documented
so that people can write correct programs.
This is true of both kinds of peeking, so I
Lucas P Melo wrote:
The problem is that the chosen
method to accomplish it would read 2 symbols (bytes) ahead and this guy
is using peek() to grab these 2 bytes. The program will seem to work
correctly most of the time, but on the 4095th byte read, he would grab 1
byte at most using peek()
Cameron Simpson wrote:
But people not using threads, or at any rate not
dedicating a thread to the reading task, don't have such luxury.
But without a dedicated thread you need to use
select() or poll(), and then buffering causes other
headaches.
Are we disputing the utility of being able
Cameron Simpson wrote:
On 16Jun2009 02:18, MRAB pyt...@mrabarnett.plus.com wrote:
My itch is that peek() _feels_ like it should be look into the buffer
but actually can block and/or change the buffer.
Can block, but not if you don't want it too. You might just want to see
what, if anything,
Cameron Simpson wrote:
Indeed, though arguably read1() is a lousy name too, on the same basis.
My itch is that peek() _feels_ like it should be look into the buffer
but actually can block and/or change the buffer.
I guess all the buffer operations should be transparent to the user if
he
MRAB wrote:
I was thinking along the lines of:
def peek(self, size=None, block=True)
I think this is fine too. :)
If 'block' is True then return 'size' bytes, unless the end of the
file/stream is reached; if 'block' is False then return up to 'size'
bytes, without blocking. The blocking
On approximately 6/16/2009 11:20 AM, came the following characters from
the keyboard of Scott David Daniels:
MRAB wrote:
I was thinking along the lines of:
def peek(self, size=None, block=True)
If 'block' is True then return 'size' bytes, unless the end of the
file/stream is reached; if
Scott David Daniels Scott.Daniels at Acm.Org writes:
MRAB wrote:
I was thinking along the lines of:
def peek(self, size=None, block=True)
If 'block' is True then return 'size' bytes, unless the end of the
file/stream is reached; if 'block' is False then return up to 'size'
bytes,
Cameron Simpson wrote:
I normally avoid
non-blocking requirements by using threads, so that the thread gathering
from the stream can block.
If you have a thread dedicated to reading from that
stream, then I don't see why you need to peek into
the buffer. Just have it loop reading a packet at a
Greg Ewing greg.ewing at canterbury.ac.nz writes:
Anything else such as peek() that doesn't explicitly
mention the buffer should fit into the abstraction
properly.
peek() doesn't fit into the abstraction since it doesn't even exist on raw
streams.
While buffered and non-buffered streams
On 17Jun2009 10:55, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Cameron Simpson wrote:
I normally avoid
non-blocking requirements by using threads, so that the thread gathering
from the stream can block.
If you have a thread dedicated to reading from that
stream, then I don't see why you
On Sat, 13 Jun 2009 12:33:46 + (UTC)
Antoine Pitrou solip...@pitrou.net wrote:
This proposal looks reasonable to me. Please note that it's too late for 3.1
anyway - we're in release candidate phase. Once you have a patch, you can post
it on the bug tracker.
Thanks I will do that.
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams? I find
it's better to steer well clear of buffered I/O objects
when doing non-blocking stuff, because they don't
On 16Jun2009 11:21, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams?
Sure, in C, python and perl quite happily. In
Cameron Simpson wrote:
On 16Jun2009 11:21, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams?
Sure, in C, python and
On 16Jun2009 02:18, MRAB pyt...@mrabarnett.plus.com wrote:
My itch is that peek() _feels_ like it should be look into the buffer
but actually can block and/or change the buffer.
Can block, but not if you don't want it too. You might just want to see
what, if anything, is currently available,
2009/6/14 Cameron Simpson c...@zip.com.au:
On 14Jun2009 15:16, I wrote:
| Is it possible to access the buffer? I see nothing in the docs.
I've just found getvalue() in IOBase. Forget I said anything.
It seems to be my day for that kind of post:-(
Where are you seeing this? Only BytesIO and
Cameron Simpson wrote:
For myself, I'd expect more often to want to see if there's stuff in the
buffer _without_ doing any raw reads at all.
What uses do you have in mind for that?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On 14Jun2009 09:21, Benjamin Peterson benja...@python.org wrote:
| 2009/6/14 Cameron Simpson c...@zip.com.au:
| On 14Jun2009 15:16, I wrote:
| | Is it possible to access the buffer? I see nothing in the docs.
|
| I've just found getvalue() in IOBase. Forget I said anything.
| It seems to be
On 15Jun2009 11:48, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
For myself, I'd expect more often to want to see if there's stuff in the
buffer _without_ doing any raw reads at all.
What uses do you have in mind for that?
It seems like whenever I want to do some kind of opportunistic but
Cameron Simpson wrote:
On 13Jun2009 12:24, Nick Coghlan ncogh...@gmail.com wrote:
| I would phrase this suggestion as users having a reasonable expectation
| that the following invariant should hold for a buffered stream:
|
| f.peek(n) == f.read(n)
|
| Since the latter method will
Nick Coghlan ncoghlan at gmail.com writes:
Since the latter method will perform as many reads of the underlying
stream as necessary to reach the requested number of bytes (or EOF),
then so should the former.
How do you propose to implement this while staying compatible with
1) unseekable raw
Frederick Reeve cylix at solace.info writes:
peek(n):
If n is less than 0, None, or not set; return buffer contents with out
advancing stream position. If the buffer is empty read a full chunk and
return the buffer. Otherwise return exactly n bytes up to _chunk
size_(not contents) with out
Antoine Pitrou wrote:
The original docstring for peek() says:
...we
do at most one raw read to satisfy it.
In that light, I'm not sure it's a bug
It may be behaving according to the docs, but is that
behaviour useful?
Seems to me that if you're asking for n bytes, then it's
Greg Ewing greg.ewing at canterbury.ac.nz writes:
I think it would be more useful if the at most one
raw read part were dropped. That would give it the
kind of deterministic behaviour generally expected
when dealing with buffered streams.
As I already told Nick: please propose an
On 14Jun2009 12:33, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Antoine Pitrou wrote:
The original docstring for peek() says:
...we
do at most one raw read to satisfy it.
In that light, I'm not sure it's a bug
It may be behaving according to the docs, but is that
On 14Jun2009 15:16, I wrote:
| Is it possible to access the buffer? I see nothing in the docs.
I've just found getvalue() in IOBase. Forget I said anything.
It seems to be my day for that kind of post:-(
--
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/
These are
Greetings,
I feel the need to point out I made a mistake. When I wrote my last email I
said the behavior had changed python3-3.1. This seems not to be the case.. I
had made that assumption because I had written code based on the looking at the
code in _pyio.py as well as the python3
Greetings,
As I'm sure you all know there are currently two implementations of
the io module one in python and one much faster implementation in C.
As I recall the python version was used in python3 and the C version is
now used by default in python3.1x. The behavior of the two is
different in
31 matches
Mail list logo
