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
Python-Dev@pyth
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,
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()
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
conce
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 to
On Sat, 13 Jun 2009 12:33:46 + (UTC)
Antoine Pitrou 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. Sometime in the next cou
On 17Jun2009 10:55, Greg Ewing 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 need to peek into
Greg Ewing 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 have a rea
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
Scott David Daniels 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, with
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 'blo
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, without blocking
I tend to prefer zero-ish defaults, how ab
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
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 wan
Cameron Simpson wrote:
On 16Jun2009 02:18, MRAB 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, up
On 16Jun2009 02:18, MRAB 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, up to n bytes.
A
Cameron Simpson wrote:
On 16Jun2009 11:21, Greg Ewing 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 some c
On 16Jun2009 11:21, Greg Ewing 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 some circumstances.
Pro
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 pla
On 15Jun2009 11:48, Greg Ewing 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
non-blocking stuff with
On 14Jun2009 09:21, Benjamin Peterson wrote:
| 2009/6/14 Cameron Simpson :
| > 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 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
http://mai
2009/6/14 Cameron Simpson :
> 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 StringIO hav
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 DoD#743
http://www.cskk.ezoshosting.com/cs/
These are but a few examples
On 14Jun2009 12:33, Greg Ewing 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
> behaviour useful?
Greg Ewing 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 implementation s
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
b
Frederick Reeve 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 a
Nick Coghlan 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 stream
Cameron Simpson wrote:
> On 13Jun2009 12:24, Nick Coghlan 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 perform as many r
On 13Jun2009 12:24, Nick Coghlan wrote:
| Frederick Reeve wrote:
| > The other point still stands though. I would like to see peek
| > changed. I am willing to write and submit changes but don't want to
| > unless others agree this is a good idea. So I put forth the
| > implementation at the bo
Frederick Reeve wrote:
> The other point still stands though. I would like to see peek
> changed. I am willing to write and submit changes but don't want to
> unless others agree this is a good idea. So I put forth the
> implementation at the bottom of this email. If its bad or you don't
> see
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 documenta
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 so
34 matches
Mail list logo
