On Wed, Jan 9, 2013 at 1:39 PM, Antoine Pitrou wrote:
>
> Hi Yuriy,
>
> For the record, it isn't necessary to cross-post. python-ideas is
> the place for discussing this, and most interested people will be
> subscribed to both python-ideas and python-dev, and therefore they get
> duplicate messag
On Wed, Jan 9, 2013 at 10:02 AM, Guido van Rossum wrote:
> Changing event loops in the middle of event processing is not a common
> (or even useful) pattern. You start the event loop and then leave it
> alone.
>
Yes. It was not-so-great morning idea.
> Yes, 'write' part is good, I should menti
On Wed, Jan 9, 2013 at 8:50 AM, Guido van Rossum wrote:
> On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum wrote:
> > On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday
> wrote:
> >> - pause() and resume() work with reading only, so they should be
> suffixed
> >> (prefixed) with read(ing), like paus
Hi Yuriy,
For the record, it isn't necessary to cross-post. python-ideas is
the place for discussing this, and most interested people will be
subscribed to both python-ideas and python-dev, and therefore they get
duplicate messages.
Regards
Antoine.
Le Wed, 9 Jan 2013 05:14:02 +0400,
Yuriy Ta
On Jan 8, 2013, at 9:14 PM, Guido van Rossum 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 using 'write' in t
On Tue, Jan 8, 2013 at 9:26 PM, Yuriy Taraday wrote:
>
>
>
> On Wed, Jan 9, 2013 at 9:14 AM, Guido van Rossum wrote:
>>
>> On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote:
>> > Should transports be bound to event loop on creation? I wonder, what
>> > would
>> > happen if someone changes curr
On Wed, Jan 9, 2013 at 9:14 AM, Guido van Rossum wrote:
> On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote:
> > Should transports be bound to event loop on creation? I wonder, what
> would
> > happen if someone changes current event loop between these calls.
>
> Yes, this is what the transpo
On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote:
> On Wed, Jan 9, 2013 at 8:31 AM, Guido van Rossum wrote:
>> On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:
>> > 1. Series of sock_ methods can be organized into a wrapper around sock
>> > object. This wrappers can then be saved and used
On Wed, Jan 9, 2013 at 8:31 AM, Guido van Rossum wrote:
> On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:
> > I've read the PEP and some things raise questions in my consciousness.
> Here
> > they are.
>
> Thanks!
>
> > 1. Series of sock_ methods can be organized into a wrapper around sock
On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum wrote:
> On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:
>> - pause() and resume() work with reading only, so they should be suffixed
>> (prefixed) with read(ing), like pause_reading(), resume_reading().
>
> Agreed.
I think I want to take tha
On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:
> I've read the PEP and some things raise questions in my consciousness. Here
> they are.
Thanks!
> 1. Series of sock_ methods can be organized into a wrapper around sock
> object. This wrappers can then be saved and used later in async-aware
On Wed, Jan 9, 2013 at 6:31 AM, Nick Coghlan wrote:
> On Wed, Jan 9, 2013 at 11:14 AM, Yuriy Taraday
> wrote:
> > 4. Why separate exception() from result() for Future class? It does the
> same
> > as result() but with different interface (return instead of raise).
> Doesn't
> > this violate the
On Tue, Jan 8, 2013 at 6:53 PM, Benjamin Peterson wrote:
> 2013/1/8 Guido van Rossum :
>> On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson
>> wrote:
>>> 2013/1/8 Yuriy Taraday :
4. Why separate exception() from result() for Future class? It does the
same
as result() but with dif
2013/1/8 Benjamin Peterson :
> 2013/1/8 Guido van Rossum :
>> On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson
>> wrote:
>>> 2013/1/8 Yuriy Taraday :
4. Why separate exception() from result() for Future class? It does the
same
as result() but with different interface (return inst
2013/1/8 Guido van Rossum :
> On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson wrote:
>> 2013/1/8 Yuriy Taraday :
>>> 4. Why separate exception() from result() for Future class? It does the same
>>> as result() but with different interface (return instead of raise). Doesn't
>>> this violate the r
On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson wrote:
> 2013/1/8 Yuriy Taraday :
>> 4. Why separate exception() from result() for Future class? It does the same
>> as result() but with different interface (return instead of raise). Doesn't
>> this violate the rule "There should be one obvious w
On Wed, Jan 9, 2013 at 11:14 AM, Yuriy Taraday wrote:
> 4. Why separate exception() from result() for Future class? It does the same
> as result() but with different interface (return instead of raise). Doesn't
> this violate the rule "There should be one obvious way to do it"?
The exception() me
2013/1/8 Yuriy Taraday :
> 4. Why separate exception() from result() for Future class? It does the same
> as result() but with different interface (return instead of raise). Doesn't
> this violate the rule "There should be one obvious way to do it"?
I expect that's a copy-and-paste error. exceptio
On Jan 4, 2013, at 8:51 PM, Guido van Rossum wrote:
> On Fri, Jan 4, 2013 at 8:19 PM, Glyph wrote:
>>
>> On Jan 4, 2013, at 3:56 PM, Guido van Rossum wrote:
>>
>>> On Mon, Dec 24, 2012 at 2:58 PM, Glyph wrote:
In my humble (but entirely, verifiably correct) opinion, thinking of this
>
On Fri, Jan 4, 2013 at 8:19 PM, Glyph wrote:
>
> On Jan 4, 2013, at 3:56 PM, Guido van Rossum wrote:
>
>> On Mon, Dec 24, 2012 at 2:58 PM, Glyph wrote:
>>> In my humble (but entirely, verifiably correct) opinion, thinking of this as
>>> a "default" is propagating a design error in the BSD socket
On Jan 4, 2013, at 3:56 PM, Guido van Rossum wrote:
> On Mon, Dec 24, 2012 at 2:58 PM, Glyph wrote:
>> In my humble (but entirely, verifiably correct) opinion, thinking of this as
>> a "default" is propagating a design error in the BSD sockets API. Datagram
>> and stream sockets have radically
On Mon, Dec 24, 2012 at 2:58 PM, Glyph wrote:
> In my humble (but entirely, verifiably correct) opinion, thinking of this as
> a "default" is propagating a design error in the BSD sockets API. Datagram
> and stream sockets have radically different semantics. In Twisted,
> "dataReceived" and "dat
On Dec 21, 2012, at 1:10 PM, Guido van Rossum wrote:
> > > TBD: Need an interface to wait for the first of a collection of Futures.
> >
> > Have you looked at Twisted's DeferredList?
> > http://twistedmatrix.com/documents/12.1.0/api/twisted.internet.defer.DeferredList.html
>
> No, I am trying t
On Dec 21, 2012, at 1:10 PM, Guido van Rossum wrote:
> > > The transport is free to buffer the bytes, but it must eventually
> > > cause the bytes to be transferred to the entity at the other end, and
> > > it must maintain stream behavior. That is, t.write(b'abc');
> > > t.write(b'def') is equiv
We were tentatively calling it "concurrent.eventloop" at the 2011 language
summit.
--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Inline.
--Guido van Rossum (sent from Android phone)
On Dec 21, 2012 11:47 AM, "Antoine Pitrou" wrote:
>
>
> Hello,
>
> > To get the current event loop, use get_event_loop(). This returns an
> > instance of the EventLoop class defined below or an equivalent
> > object. It is possible that get_ev
Hello,
> To get the current event loop, use get_event_loop(). This returns an
> instance of the EventLoop class defined below or an equivalent
> object. It is possible that get_event_loop() returns a different
> object depending on the current thread, or depending on some other
> notion of contex
On Fri, Dec 21, 2012 at 11:06 AM, Jesse Noller wrote:
> I really do like tulip as the name. It's quite pretty.
I chose it because Twisted and Tornado both start with T. But those
have kind of dark associations; I wanted to offset that with something
lighter. (OTOH we could use a black tulip as a
On Friday, December 21, 2012 at 1:57 PM, Guido van Rossum wrote:
> Dear python-dev *and* python-ideas,
>
> I am posting PEP 3156 here for early review and discussion. As you can
> see from the liberally sprinkled TBD entries it is not done, but I am
> about to disappear on vacation for a few we
29 matches
Mail list logo
