[+async-...@python.org , which is the new home for
these kinds of discussions]
Tornado's tests are now failing on nightly with "TypeError: can't send
non-None value to a FutureIter":
https://travis-ci.org/tornadoweb/tornado/jobs/167252979
-Ben
On Tue, Oct 11, 2016 at 3:55 PM INADA Naoki wrote:
On Mon, Jan 25, 2016 at 4:45 PM, Victor Stinner
wrote:
> Hi,
>
> Short story: I don't want to maintain Trollius anymore. If anyone is
> using it, please say it. Otherwise, I will simply make it clear that
> Trollius must not be used anymore.
>
> Since almost no library support Trollius, I'm not s
e of debug? I'd like to see the result of my test code.
>
> You can see the return value of debug() in f.result(). But `debug()` is
`down`, not `up` relative to the breakpoint, and you can't look into it
because it has already returned. To see its locals you'll have to set a
breakpoin
If the event loop is already running, then Tornado's IOLoop.run_sync()
won't work either (it may appear to work because we don't do enough
checking for improper combinations of run_sync() and start(), but it's not
safe).
Instead, you should do something like `debug().add_done_callback(lambda f:
pd
On Sat, May 16, 2015 at 10:50 AM, Imran Geriskovan <
imran.gerisko...@gmail.com> wrote:
> > So asynchronous object creation should be done by a factory coroutine,
> > and not by calling the standard constructor machinery.
>
> It may be done by a factory or a second async helper function
> method o
On Wed, Feb 25, 2015 at 12:17 PM, Antoine Pitrou
wrote:
> On Wed, 25 Feb 2015 10:42:23 -0500
> Ben Darnell wrote:
> > > Maybe we should modify asyncio.Queue and asyncio.Lock to make them
> > > thread-safe?
> > >
> >
> > -1 on modifying asyncio.Loc
On Wed, Feb 25, 2015 at 8:43 AM, Victor Stinner
wrote:
> Hi,
>
> On IRC, someone told me that it took him hours to understand that
> asyncio.Queue is not thread-safe and he expected asyncio.Queue to be
> thread-safe. I modified the asyncio documentation to mention in almost
> all classes that asy
On Thu, Feb 12, 2015 at 11:31 AM, Victor Stinner
wrote:
> 2015-02-12 17:12 GMT+01:00 Andrew Svetlov :
> > I like to have simple markup for coroutines but -1 for using return
> > annotation for that.
> > Return annotation is for return value description, not for function
> itself.
>
> A coroutine
It's too strict IMHO. Where is this restriction coming from in the PEP? In
"the intention is to stop short of polling for I/O, and not to run any
callbacks scheduled in the future" I read that as a SHOULD and not a MUST;
it goes on to say that implementations have freedom in terms of how much of
th
On Wed, Feb 11, 2015 at 10:01 AM, Victor Stinner
wrote:
> By the way, Trollius has currently the performance issue of recursive
> coroutines. It doesn't use yield-from and it currently creates a new
> task for each sub-coroutine. I read somewhere that Tornado solved this
> issue by following coro
fetched %d bytes' % len(resp.body))
if __name__ == '__main__':
tornado.platform.asyncio.AsyncIOMainLoop().install()
asyncio.get_event_loop().run_until_complete(main())
>
> On Sun, Jan 25, 2015 at 5:19 PM, Ben Darnell wrote:
>
>> On Sun, Jan 25, 2015 at 6:11 PM
On Sun, Jan 25, 2015 at 6:11 PM, Guido van Rossum wrote:
> On Sun, Jan 25, 2015 at 2:52 PM, Ben Darnell wrote:
>
>> On Sun, Jan 25, 2015 at 5:31 PM, Guido van Rossum
>> wrote:
>>
>>> I'm probably a bit dense today, but without browsing the code I'm
ython repo?
-Ben
>
> On Sun, Jan 25, 2015 at 9:42 AM, Ben Darnell wrote:
>
>> In Tornado 4.1 [1], I've added a functools.singledispatch-based registry
>> for objects that can be yielded in coroutines. This allows for Future-like
>> objects from different fr
In Tornado 4.1 [1], I've added a functools.singledispatch-based registry
for objects that can be yielded in coroutines. This allows for Future-like
objects from different frameworks to be mixed seamlessly in the same
coroutine (We currently have support for tornado.concurrent.Future,
concurrent.fut
5 at 12:40 PM, Andrew Svetlov > wrote:
>
>> Anyway, your traceback processing is very useful in Python 3 code
>> debugging .
>> Thanks to much.
>>
>> On Sat, Jan 10, 2015 at 10:29 PM, Ben Darnell wrote:
>> > FWIW, Tornado's version of Future
FWIW, Tornado's version of Future adds exc_info and set_exc_info methods so
we can save tracebacks on python 2:
http://www.tornadoweb.org/en/stable/concurrent.html#tornado.concurrent.Future.set_exc_info
This works pretty well for pure-tornado coroutines, although it doesn't
help if you're interact
On Mon, Oct 6, 2014 at 7:25 AM, Antoine Pitrou wrote:
> On Mon, 6 Oct 2014 07:11:50 -0400
> Donald Stufft wrote:
> >
> > My problem with _overlapped is mostly that it required a compiler. I’m
> idly considering what it’d take to give pip some concurrency and one of the
> requirements there is th
On Tue, Jul 22, 2014 at 6:00 PM, Tobias Oberstein <
tobias.oberst...@gmail.com> wrote:
> So I guess what I am after is "six for asyncio/Twisted" ;)
Isn't "six for asyncio/Twisted" covered by the fact that you can implement
one event loop in terms of another? Idiomatic asyncio code and idiomatic
On Fri, May 23, 2014 at 10:37 AM, Guido van Rossum wrote:
> I very much like the idea of having at least the Future class of either
> framework be compatible with the event loop classes of the other.
>
It would also be nice if asyncio could accept tornado Futures as well
(which do not implement
On Wed, Mar 12, 2014 at 5:41 AM, Luca Sbardella wrote:
> On 12 March 2014 07:28, Chris Withers wrote:
>
>>
>> So, I see python now has a plethora of async frameworks and I need to try
>> and pick one to use from:
>>
>> - asyncio/tulip
>> - tornado
>> - twisted
>>
>> From my side, I'm looking to e
Tornado doesn't have any support for the functionality you're describing.
It looks like urwid is monkey patching tornado:
https://github.com/wardi/urwid/blob/master/urwid/main_loop.py#L915
Personally I'm -1 on this feature; "idleness" is ill-defined and will
either run the function too often or to
On Fri, Jan 24, 2014 at 10:48 AM, Victor Stinner
wrote:
> 2014/1/24 Ben Darnell :
> > The epoll change in
> >
> https://code.google.com/p/tulip/source/detail?r=5b7e17a75ba4b9bdaab5969a787e904137a53aee
> > doesn't work. An integer number of milliseconds cannot be
The epoll change in
https://code.google.com/p/tulip/source/detail?r=5b7e17a75ba4b9bdaab5969a787e904137a53aeedoesn't
work. An integer number of milliseconds cannot be represented
exactly as a floating-point number of seconds, so you lose precision when
passing the adjusted timeout into epoll_wait a
+1 to some form of slow-callback detection.
Tornado's version of this idea works a little differently: it uses
signal.setitimer() and logs a stack trace from the signal handler. This
has the advantage that it works even for deadlocks or infinite loops that
will never return normally, and it also
-Ben
>
> Victor, any plans for Windows support? I guess porting "_winapi" would be
> the biggest issue. Compiling "overlapped.c" is possible with small changes
> (I could send the patch if you are interested).
>
> On Tuesday, January 7, 2014 6:56:17 AM
ket objects through sock.close() instead of
clobbering them with os.close(fd), but that doesn't explain why we have
only seen this with the asyncio-based IOLoop.
On Fri, Jan 3, 2014 at 11:13 PM, Ben Darnell wrote:
> On Fri, Jan 3, 2014 at 9:12 PM, Victor Stinner
> wrote:
>
>
On Fri, Jan 3, 2014 at 9:12 PM, Victor Stinner wrote:
> 2013/12/31 Ben Darnell :
> > I just tried running the Tornado test suite with this backported package
> and
> > it mostly works.
>
> Wow, great!
>
> > There are two issues:
> >
> > * Tornado
I just tried running the Tornado test suite with this backported package
and it mostly works. There are two issues:
* Tornado uses hasattr(ssl, 'SSLContext') to determine whether or not it
can use the APIs introduced in Python 3.2; the incomplete version of
SSLContext patched in by this package c
28 matches
Mail list logo
