On 3/4/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 3/4/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
>
> > > .nonblockflush() would be fine with me, but I don't think .flush()
> > > should block on a non-blocking object. ...
>
> I don't thi
On 3/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I'm having trouble seeing what the use case is for
> the buffered non-blocking writes being discussed here.
>
> Doing asynchronous I/O usually *doesn't* involve
> putting the file descriptor into non-blocking mode.
> Instead you use select() or equ
On 3/4/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> > .nonblockflush() would be fine with me, but I don't think .flush()
> > should block on a non-blocking object. ...
I don't think flush should even be called on an object that is
(intentio
I'm having trouble seeing what the use case is for
the buffered non-blocking writes being discussed here.
Doing asynchronous I/O usually *doesn't* involve
putting the file descriptor into non-blocking mode.
Instead you use select() or equivalent, and only
try to read or write when the file is repo
Raymond Hettinger wrote:
> def contact_info_update(timestamp, sequence_number, (name, address,
> phone,
> email), backup=True):
Things like that are probably better done with something
like the named-tuple idea that was discussed recently.
Writing code that depends on long sequences having
On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 3/1/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Why do non-blocking operations need to use the same methods when
> > they're clearly not the same semantics? Although long,
> > .nonblockflush() would be explicit and allow .flush() to sti
On 3/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Ka-Ping Yee]
> > In summary, all of the arguments for removing this feature are of the
> > form "It won't hurt very much if we remove the feature"; the arguments
> > for keeping the feature are of the form "This feature is useful and
> > go
On 3/1/07, Mike Verdone <[EMAIL PROTECTED]> wrote:
> When write is called check if the buffer is bigger than buffer_size.
> If it is attempt to pre-flush the buffer. If we can't pre-flush, raise
> BlockingIO error.
I'd much rather see dynamically-sized buffers. If it works as you
describe, then a
On 3/1/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Why do non-blocking operations need to use the same methods when
> they're clearly not the same semantics? Although long,
> .nonblockflush() would be explicit and allow .flush() to still block.
.nonblockflush() would be fine with me, but I don't
[Ka-Ping Yee]
> In summary, all of the arguments for removing this feature are of the
> form "It won't hurt very much if we remove the feature"; the arguments
> for keeping the feature are of the form "This feature is useful and
> good for the language." Notice the asymmetry: there are no argument
On 3/4/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Fri, 2 Mar 2007, Brett Cannon wrote:
> > the removal of the automatic unpacking of sequence
> > arguments when a tuple parameter is present in a function's signature
> > (e.g., the ``(b, c)`` in ``def fxn(a, (b, c), d): pass``).
>
> As I think
On Fri, 2 Mar 2007, Brett Cannon wrote:
> the removal of the automatic unpacking of sequence
> arguments when a tuple parameter is present in a function's signature
> (e.g., the ``(b, c)`` in ``def fxn(a, (b, c), d): pass``).
As I think most people know by now, it makes me quite sad to see these
g
On 3/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/4/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 3/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I see lukewarm support for keeping these at most, and probably
> > > lukewarm support for removing them at well. That means I
On 3/4/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I see lukewarm support for keeping these at most, and probably
> > lukewarm support for removing them at well. That means I get to decide
> > and nobody will care much (for once :-). So m
On 3/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/3/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 3/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > I have mixed feelings; I won't go so far as to say I oppose removing
> > > tuple-arguments, but some of the problems do have other s
On 3/3/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I have mixed feelings; I won't go so far as to say I oppose removing
> > tuple-arguments, but some of the problems do have other solutions.
>
> Sure some of them have other solutions, but that
16 matches
Mail list logo
