"tomer filiba" <[EMAIL PROTECTED]> writes:
> read(x) guarantees to return x bytes, or EOFError otherwise
> (and also restoing the stream position).
This is a poor choice of the fundamental operation. For example when
recoding bytes to characters, an analogous interface for a character
stream is i
> "tomer" == tomer filiba <[EMAIL PROTECTED]> writes:
> read(x) guarantees to return x bytes, or EOFError otherwise (and
> also restoing the stream position).
This would require arbitrarily large buffer for a socket stream. I'm
unsure if that's desiable. Maybe you could move the buff
>> def async_read(self, count, callback)
>> def async_write(self, data, callback)
>I think many people would be happy if the proposal would use the
>Deferred abstraction which is built in Twisted. :-)
I almost agree. Not sure whether a Defered implementation in python core would be prefe
Le samedi 29 avril 2006 à 21:10 +0200, tomer filiba a écrit :
> and if we do that already, perhaps we should introduce async
> operations as a
> built-in feature? .NET does (BeginRead, EndRead, etc.)
> def async_read(self, count, callback)
> def async_write(self, data, callback)
I think m
and one small thing i forgot to mention --
file.read/write work with the new bytes() type, while
textfile.read/write work with strings (depends on the encoding)
-tomer
On 4/30/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> > I don't
> > want to make the 90% case require hardly any memorizing of
> I don't
> want to make the 90% case require hardly any memorizing of what
> readers I need in what order.
...
> See, this is what I am worried about. I **really** like not having to
> figure out what I need to do to read by lines from a file. If the
> FileStream object had an __iter__ that did
"Brett Cannon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> See, this is what I am worried about. I **really** like not having to
> figure out what I need to do to read by lines from a file. If the
> FileStream object had an __iter__ that did the proper wrapping with
> LinedBuf
On 4/29/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i first thought on focusing on the socket module, because it's the part that
> bothers me most, but since people have expressed their thoughts on
> completely
> revamping the IO stack, perhaps we should be open to adopting new ideas,
> mainly fr
i first thought on focusing on the socket module, because it's the part thatbothers me most, but since people have expressed their thoughts on completelyrevamping the IO stack, perhaps we should be open to adopting new ideas,
mainly from the java/.NET world (keeping the momentum from the previous p
