On Wed, Jan 9, 2013 at 12:14 AM, Guido van Rossum gu...@python.org wrote:
But which half? A socket is two independent streams, one in each
direction. Twisted uses half_close() for this concept but unless you
already know what this is for you are left wondering which half. Which
is why I like
Well, if we're at the bikeshedding about names stage, that means that no
serious issues with the proposal are left. So it's a sign of progress.
On Wed, Jan 9, 2013 at 12:42 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
Is this thread really ready to migrate to python-dev when we're still
On Wed, Jan 9, 2013 at 8:55 PM, Yuriy Taraday yorik@gmail.com wrote:
My interns told me that they remember EOF as special object only from high
school when they had to study Pascal. I guess, in 5 years students won't
understand how one can write an EOF. (and schools will finally replace
Is this thread really ready to migrate to python-dev when we're still
bikeshedding method names?
Yuriy Taraday writes:
But which half? A socket is two independent streams, one in each
direction. Twisted uses half_close() for this concept but unless you
already know what this is for you
On Fri, Jan 4, 2013 at 2:38 PM, Dustin Mitchell djmit...@gmail.com wrote:
As the maintainer of a pretty large, complex app written in Twisted, I think
this is great. I look forward to a future of being able to select from a
broad library of async tools, and being able to write tools that can
As the maintainer of a pretty large, complex app written in Twisted, I
think this is great. I look forward to a future of being able to select
from a broad library of async tools, and being able to write tools that can
be used outside of Twisted.
Buildbot began, lo these many years ago, doing
Looks reasonable to me :) Comments:
create_transport combines a transport and a protocol. Is that process
reversible? that might seem like an exotic thing (and I guess it kind of
is), but I've wanted this e.g for websockets, and I guess there's a few
other cases where it could be useful :)
As far as I understand, yield from will always work, because a Future
object can act like an iterator, and you can delegate your own generator to
this iterator at the place of yield from.
yield only works if the parameter behind yield is already a Future
object. Right Guido?
In case of sleep,
On Fri, Dec 21, 2012 at 1:04 PM, Laurens Van Houtven _...@lvh.cc wrote:
Looks reasonable to me :) Comments:
create_transport combines a transport and a protocol. Is that process
reversible? that might seem like an exotic thing (and I guess it kind of
is), but I've wanted this e.g for
On Fri, Dec 21, 2012 at 2:26 PM, Jonathan Slenders jonat...@slenders.be wrote:
As far as I understand, yield from will always work, because a Future
object can act like an iterator, and you can delegate your own generator to
this iterator at the place of yield from.
yield only works if the
On Fri, Dec 21, 2012 at 5:17 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
On Fri, Dec 21, 2012 at 8:02 PM, Guido van Rossum gu...@python.org wrote:
... snip ...
In PEP 3156 conformant code you're supposed always to use 'yield
from'. The only time you see a bare yield is when it's part
On Fri, Dec 21, 2012 at 8:02 PM, Guido van Rossum gu...@python.org wrote:
... snip ...
In PEP 3156 conformant code you're supposed always to use 'yield
from'. The only time you see a bare yield is when it's part of the
implementation's internals. (However I think tulip actually will
handle a
12 matches
Mail list logo
