L should I use?
>
> Thanks!
>
> Luciano
>
> --
> Luciano Ramalho
> | Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> | Professor em: http://python.pro.br
> | Twitter: @ramalhoorg
>
--
--Guido van Rossum (python.org/~guido)
rite future and to the socket
> * BaseSubprocessTransport constructor now calls the internal
> _connect_pipes()
> method (previously called _post_init()). The constructor now accepts an
> optional waiter parameter to notify when the transport is ready.
> * send_signal(), terminate() and kill() methods of BaseSubprocessTransport
> now
> raise a ProcessLookupError if the process already exited.
> * Add run_aiotest.py to run the aiotest test suite
> * Add release.py script to build wheel packages on Windows and run unit
> tests
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
h
specifies for both wait() and as_completed() that the tasks being waited
for are unaffected when the timeout goes off.
On Fri, Mar 6, 2015 at 8:59 AM, Gustavo Carneiro
wrote:
> On 5 March 2015 at 19:38, Guido van Rossum wrote:
>
>> Well, TimeoutError is raised when the timeout
*not* cancelled (if you want that to happen you should catch
TimeoutError and cancel them yourself).
On Thu, Mar 5, 2015 at 10:35 AM, Gustavo Carneiro
wrote:
>
>
> On 5 March 2015 at 18:10, Guido van Rossum wrote:
>
>> On Thu, Mar 5, 2015 at 9:04 AM, Gustavo
;. The cancellation mechanism already works by
sending an exception (CancelledError) into the blocked task (i.e. cf, which
represents _wait_for_one() in as_completed()). This exception normally
comes right out, and that's the desired behavior here. I don't think a
different exception should be raised, unless I am missing something?
--
--Guido van Rossum (python.org/~guido)
t; On 3 March 2015 at 19:34, Guido van Rossum wrote:
>
>> I looked a bit more. The only thing that ever waits is the caller in the
>> for-loop (for f in as_completed(...): x = yield from f; ...). It will
>> always wait for _wait_for_one(), which in turn will always wait for
&g
On Tue, Mar 3, 2015 at 2:39 PM, Nicolas Di Pietro wrote:
> Hi Guido,
>
> Thank you for taking some time to answer this.
>
> 2015-03-03 6:05 GMT+01:00 Guido van Rossum :
>
>> I'll try to give some hints on Nicolas's original question. I agree with
>> Lucian
On Tue, Mar 3, 2015 at 2:06 PM, Luciano Ramalho wrote:
> On Tue, Mar 3, 2015 at 1:49 AM, Guido van Rossum wrote:
> > It's exceedingly subtle -- that's why the docstring contains an example
> of
> > how to use it.
> >
> > Note the final two li
ly
>> set the _log_destroy_pending attribute of these tasks to False. What
>> do you think?
>
>
>> Victor
>>
>
>
>
> --
> Gustavo J. A. M. Carneiro
> Gambit Research
> "The universe is always one step beyond logic." -- Frank Herbert
>
--
--Guido van Rossum (python.org/~guido)
ing right now with those new devices and, if they could
> find something that can help them fast to implement servers, I think (but
> I'm no specialist) they could enjoy discovering and using python.
> >
> > Thank you for your advices and example (and for those that contribute to
> python, your hard work)
> >
> > Nicolas
>
>
>
> --
> Luciano Ramalho
> Twitter: @ramalhoorg
>
> Professor em: http://python.pro.br
> Twitter: @pythonprobr
>
--
--Guido van Rossum (python.org/~guido)
I don't see where a
> future can be wrapped in another future. I only saw that async() is
> called on each item of the fs parameter, so coroutine objects are
> wrapped into future. So I propose:
>
> """
> Note: The futures f are not necessarily members of fs. Coroutine
> objects of fs are
> wrapped in futures.
> """
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
rt from those in the fs argument may be yielded
> by as_completed?
>
> Thanks!
>
> --
> Luciano Ramalho
> Twitter: @ramalhoorg
>
> Professor em: http://python.pro.br
> Twitter: @pythonprobr
>
--
--Guido van Rossum (python.org/~guido)
and never
> sends them, and doesn't do anything complicated with them, then a
> synchronous server is probably just as good (IMHO).
>
> Regards
>
> Antoine.
>
>
>
--
--Guido van Rossum (python.org/~guido)
solution
(which is what most people use).
--
--Guido van Rossum (python.org/~guido)
e" a queue between multiple coroutines running in different
> threads (in different event loops)
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
gt;>>
>
> Here's a naive workaround:
>
> def iscoroutinefunction(func):
> if asyncio.iscoroutinefunction(func):
> return True
>
> return asyncio.iscoroutinefunction(getattr(func, 'func', None))
>
>
> What do you think?
>
> Best regards
> Ron Cohen
> CTO & co-founder @ Opbeat
>
--
--Guido van Rossum (python.org/~guido)
What would Twisted do? (WWTD)
On Wed, Jan 28, 2015 at 6:20 PM, Victor Stinner
wrote:
> 2015-01-29 2:47 GMT+01:00 Guido van Rossum :
> > Doesn't the exception bubble up to the caller of create_connection()?
>
> Yes, it does.
>
> > So what's the problem?
> coroutine handling an incoming client connection for a server. We may
> also change other functions creating pairs of (transport, protocol).
> These methods currently only call transport.close() on error.
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
shouldn't try to "fix" this.
> I have pending (and working!) patches for signal handling, I should update
> them.
>
That sounds good.
--
--Guido van Rossum (python.org/~guido)
th the
Twisted event loop, not with the Tulip event loop.) I assume there's a way
this is done in Tornado and an analogous way should work for Tulip too. But
what is it? Is this part in your Tornado patch too?
On Sun, Jan 25, 2015 at 5:19 PM, Ben Darnell wrote:
> On Sun, Jan 25, 2015
https://code.google.com/p/tulip/issues/detail?id=197
>
> "Investigate IocpProactor.accept_pipe() special case (don't register
> overlapped)"
> https://code.google.com/p/tulip/issues/detail?id=204
>
> "race condition when cancelling a _WaitHandleFuture"
> http://bugs.python.org/issue23095
>
> "race condition related to IocpProactor.connect_pipe()"
> http://bugs.python.org/issue23293
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
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 not
>> entirely sure how your thing works.
>>
>
> Sorry, the imp
ttp://www.google.com'))
> a_body2 = yield asyncio.async(a_response2.read())
> print('aiohttp2: read %d bytes with status code %d' %
> (len(a_body2), a_response2.status))
>
> if __name__ == '__main__':
>
> tornado.ioloop.IOLoop.configure(tornado.platform.asyncio.AsyncIOMainLoop)
> tornado.ioloop.IOLoop.current().run_sync(main)
>
>
--
--Guido van Rossum (python.org/~guido)
help
> > will be most welcome!
> >
> > I will report back as soon as I have something to show (or questions to
> > ask).
> >
> > Best,
> >
> > Luciano
> >
> >
> > On Saturday, May 17, 2014 at 9:10:01 PM UTC-3, Guido van Rossum wrot
ude that in practice, close() should not be called at all
> unless your own code actually created the loop instead of merely
> fetching it with asyncio.get_event_loop()?
>
> Is that a sensible recommendation?
>
> Cheers,
>
> Luciano
>
>
>
> --
> Luciano Ramalho
I used the ThirdParty wiki page to keep these info:
> https://code.google.com/p/tulip/wiki/ThirdParty#Filesystem
>
> I don't understand the status on Windows when the ProactorEventLoop is
> used: are filesystem operation blocking or not?
>
> Latest discussion on the Linux kernel: http://lwn.net/Articles/612483/
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
#x27;t have a sock
> argument like the create_connection does.
>
> I did search the internet for quite a while and didn't see any examples or
> anyone really talking about udp broadcast. Sorry if I just don't understand
> python enough and it's just some trivial method passing thing.
>
> thanks
>
--
--Guido van Rossum (python.org/~guido)
removed it. I also
> removed wheel packages of asyncio 3.4.1 by mistake :-/ I rebuilt and
> uploaded them again (using the tag 3.4.1).
>
> I also documented the release process in setup.py (in a comment).
>
> I hope that the next release will be done with less mistakes. I hope
> that release.py and tox will help for the release process.
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
dition, timeout):
> wait_task = asyncio.async(condition.wait())
> loop.call_later(timeout, wait_task.cancel)
> try:
> yield from wait_task
> return True
> except asyncio.CancelledError:
> return False
>
>
> Any thoughts?
>
--
--Guido van Rossum (python.org/~guido)
yield
>
> def main():
> for i in range(5):
> yield do_little()
>
> import logging
> logging.basicConfig(level=logging.INFO)
> loop = asyncio.get_event_loop()
> loop.create_task(main())
> loop.run_forever()
> ==
>
>
> Excuse the boilerplate code, tested to run on MicroPython too. The diff
> is:
>
> -loop.create_task(do_little())
> -yield
> +yield do_little()
>
>
> --
> Best regards,
> Paul mailto:pmis...@gmail.com
>
--
--Guido van Rossum (python.org/~guido)
Is that
> really the intended use of asyncio.wait? Is there something more
> appropriate to my situation?
>
> To recap, I want to wait on the first completed task of two (or more)
> heterogenous task types. And then I want to process results from each task
> type in a disti
ovement ideas), I hope to share them some time later, and hope
> for positive and productive attention to them too.
>
>
> --
> Best regards,
> Paul mailto:pmis...@gmail.com
>
--
--Guido van Rossum (python.org/~guido)
I still haven't gotten to this. But at least I've tagged 3.4.2 in the tulip
repo (as the rev that matched the asyncio package in the CPython 3.4.2 tree
exactly).
On Thu, Oct 9, 2014 at 6:04 PM, Guido van Rossum wrote:
> Yeah, we should release a Tulip 3.4.2 release that'
se, but all the task tests are skipped.
>> > Where can I find this test.script_helper module?
>> >
>> > --
>> > Gustavo J. A. M. Carneiro
>> > Gambit Research
>> > "The universe is always one step beyond logic." -- Frank Herbert
>>
>
>
>
> --
> Gustavo J. A. M. Carneiro
> Gambit Research
> "The universe is always one step beyond logic." -- Frank Herbert
>
--
--Guido van Rossum (python.org/~guido)
On Sun, Oct 12, 2014 at 3:37 PM, Victor Stinner
wrote:
> 2014-10-12 21:55 GMT+02:00 Guido van Rossum :
> > So you're only concerned about the streams example, right?
>
> Oh no sorry, my question was general. It's just that I discovered the
> issue when worki
e like for TCP).
The connection_lost() callback is only called when the transport is closed
using transport.close().
> For error_received, the documentation is here:
>
> https://docs.python.org/dev/library/asyncio-protocol.html#asyncio.DatagramProtocol.error_received
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
can then use
transport.close()
loop.run_until_complete(protocol.completed)
loop.close()
NOTE: If an error happens to the transport the loop.close() call won't
actually be reached; you can solve this in various ways, e.g. by not
calling set_exception(), or using try/finally.
--
--Guido van Rossum (python.org/~guido)
> if data:
> break
>
> Is there another way to wait until the socket is closed? My wait_eof()
> looks complex, I don't want to put it in a simple example.
>
> Or maybe I should not wait until a socket is closed? Is it safe to
> call writer.close() and exit immediatly? The scheduled callback which
> will close the socket may not be called immediatly.
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
i,
>
> Python 3.4.2 has been released. What's the status of Tulip? Can we
> release a version 3.4.2 too?
>
> FYI Trollius 1.0.2 should be synchronized with Python 3.4.2.
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
error', '"global name \'s\' is not defined"') ('done:', 1, '; ok:', 0)
>
> Can you please give me some hints?
>
> Looking forward to your kind help. Kind regards. Marco
>
--
--Guido van Rossum (python.org/~guido)
rg/pypi/aiohttp/0.9.1
>
>
> A few questions:
> 1) Does anyone have a xml-rpc library for asyncio?
>
> 2) If I need to build my own xml-rpc server library for asyncio, what's
> the best starting point?
>
>
--
--Guido van Rossum (python.org/~guido)
the
> porting work. Any hint about the proper procedure in submitting for a
> first-time contributor is appreciated.
>
> Best regards,
>
>
> 2014-09-25 18:33 GMT+02:00 Guido van Rossum :
>
>> It's totally fine to submit patches for this. I have never seen a use
&g
y means of support for EVENT_EXCEPTION in addition to
> EVENT_READ and EVENT_WRITE.
>
> What about adding support for this to python selectors and asyncio? Would
> patches for something like this be accepted or is this out of the question?
>
> Best regards,
>
>
--
--Guido van Rossum (python.org/~guido)
d to wait on the shared queue? The pipe was only
> relevant because I could monitor it through IOCP.
>
> Arve
>
> On Wed, Sep 24, 2014 at 6:27 PM, Guido van Rossum > wrote:
>
>> Maybe the following can be made to work? Use two threads, each with an
>>
Say again, the problem not in missing add_reader/add_writer but in 0MQ
> library implementation details.
>
> On Wed, Sep 24, 2014 at 5:57 PM, Guido van Rossum
> wrote:
> > I don't know much about the Windows primitives used by Proactor -- the
> best
> > I can re
I
> would like to combine it with ProactorEventLoop.
>
> Thanks,
> Arve
>
--
--Guido van Rossum (python.org/~guido)
t out cancel method would still be a very nice thing to
> have.
>
Perhaps, but clearly we're not even scratching the surface of how it should
behave. I haven't heard from enough people with other use cases that would
actually be helped by the same helper to warrant adding the new API
ple
cancellations simultaneously is nearly impossible. It's almost always
better to bite down and do the right thing, which to keep track of the
higher-level activities you have going and come up with a way to shut those
down in an orderly fashion, rather than just shooting all tasks.
--
--Guido van Rossum (python.org/~guido)
shouldn't change anymore, but
> maybe we can add a new method, e.g. BaseEventLoop.cancel(),
> which cancels all running coroutines.
>
> Greetings
>
> Martin
>
--
--Guido van Rossum (python.org/~guido)
).
> Any feedback would be appreciated.
>
> ThinkChaos
>
--
--Guido van Rossum (python.org/~guido)
yield directly from my error()
> coro. This also doesn't repro if I throw a RuntimeError instead of a
> KeyboardInterrupt.
>
> Could gather() be removing a directory? Or maybe making my context manager
> exit twice?
>
--
--Guido van Rossum (python.org/~guido)
p()
> coro = loop.create_server(EchoServer, '127.0.0.1', 8889)
> server = loop.run_until_complete(coro)
> print('serving on {}'.format(server.sockets[0].getsockname()))
>
> try:
> loop.run_forever()
> except KeyboardInterrupt:
> print("exit")
> finally:
> server.close()
> loop.close()
>
> *Problem:*
>
> When I run the code, client.py immediately returns. This is what is
> returned from serverone.py:
>
> data received: Task()
>
> I've tried yield from's, putting things to @asyncio.coroutine decorated
> methods, but either it tries to return generators, tasks, or client.py
> hangs.
>
>
> TL;DR: I need to run client.py and have it print out the string "Hello -
> ServerTwo"
>
> Thanks for reading!
>
--
--Guido van Rossum (python.org/~guido)
ambda: future.set_result(True))
> yield from future
> print('Ready')
> print("exit", future)
>
> loop = asyncio.get_event_loop()
> loop.create_task(main())
> loop.run_forever()
> loop.close()
> ---
>
> => AssertionError: _step(): alre
On Tue, Aug 26, 2014 at 2:04 AM, Martin Richard
wrote:
> On Monday, August 25, 2014 8:31:04 PM UTC+2, Guido van Rossum wrote:
>
>> On Mon, Aug 25, 2014 at 6:25 AM, Martin Richard
>> wrote:
>>
>>> On Monday, August 25, 2014 2:03:36 PM UTC+2, Victor Stinner wr
e found this: https://gist.github.com/kunev/f83146d407c81a2d64a6
>
> Is it ok, or do you have a better suggestion ?
>
> Regards.
>
--
--Guido van Rossum (python.org/~guido)
e protocol. The protocol is not
>> directly related to the buffer.
>>
>
> So on which object do these limits apply?
>
On the StreamWriter object.
> An example of situation which I can't solve is when I want to run the loop
> until the transport wrote everything. I think there is currently no way to
> synchronize on this event.
>
Why do you want to do that? It seems you are still struggling with figuring
out how to use asyncio well, hence your requests for features it does not
want to provide. Or are you trying to wrap it into an existing API that you
cannot change for backwards compatible reasons? In that case perhaps you
should try to use bare protocols and transports instead of stream readers
and writers.
--
--Guido van Rossum (python.org/~guido)
rstanding the point of ".wait()"/".wait_for()"? What does a
> task have to do when it gets cancelled? Should I assume that all tasks are
> scheduled and running during ".wait()"? Am I supposed to assume that any
> cancelled task is a task that has completed but we are discarding its
> results? Why doesn't "Queue.get()" offer a timeout parameter?
>
> Thanks in advance.
>
>
--
--Guido van Rossum (python.org/~guido)
7;m not sure if the behavior can be considered as a bug in tulip or if
> it's because I rely on a bad design, but in this case I'm sure that when I
> except a BaseException, I don't want to run the loop anymore.
>
> A simple fix for this in tulip would be to set self._log_destroy_pending
> to False when calling cancel().
>
> Cheers,
> Martin
>
--
--Guido van Rossum (python.org/~guido)
.
>
> Anyway, to make a long story short, returning a Deferred from a test is a
> very advanced, somewhat risky feature that you should use only if you have
> no other tools at your disposal that do what you want to do. And there are
> probably more tools to do what you want to do than you might initially
> think :).
>
> Happy testing,
>
> -glyph
>
>
--
--Guido van Rossum (python.org/~guido)
b -- or perhaps to the
tulip project (since I assume your framework might have dependencies on
Twisted and/or Trollius, which isn't really appropriate for the stdlib).
It seems you're currently in stage 2, but you seem to be asking to jump
straight to stage 5?
--
--Guido van Rossum (python.org/~guido)
ething like:
>> >
>> > def handle_client(transport):
>> > while True:
>> > buf = yield from transport.read(4096)
>> > # handle request
>> >
>> > # read some result from database without blocking other
>> coroutine.
>> > result = yield from block_read_from_database()
>> >
>> > loop.create_server(handle_client, '127.0.0.1', 3000)
>> >
>> >
>> > Thanks.
>> >
>> > --
>> > http://yi-programmer.com/
>>
>
>
> --
> http://yi-programmer.com/
>
--
--Guido van Rossum (python.org/~guido)
use socket.shutdown(SHUT_WR) in write_eof()
> for the subprocess stdin?
>
>
> (4) Non-inheritable file descriptors for the socketpair
>
> By the way, on Python 3.3, _UnixSubprocessTransport._start() should
> make the file descriptors of the socket pair non-inheritable. (Or we
> may rely on subprocess which creates a pipe with non-inheritable file
> descriptors ...)
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
nt loop policy for the
> ProactorEventLoop. Is it a choice or we just forgot it?
>
> By the way, Guido asked me if get_event_loop() is supposed to return
> None or raise an error if there is no event loop in the current
> thread.
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
ctorSocketTransport
> fd=7 read=polling write=>,
> )
> ...
> DEBUG:asyncio:poll took 200.113 ms: 1 events
> ...
> DEBUG:asyncio:<_SelectorSocketTransport fd=7 read=polling write= bufsize=0>> received EOF
> DEBUG:asyncio:Close <_UnixSelectorEventLoop running=False closed=False
> debug=True>
> ---
>
> I'm also working on a patch to log subprocess events:
> https://code.google.com/p/tulip/issues/detail?id=184
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
or a
> subclass of asyncio.Task."
>
> > However, it could simply inherit from asyncio.Future.
>
> If you do that, it may break code in the future, if asyncio is
> modified. It's safer to use a sublass of Task. Don't you think so?
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
Cool, I think we have a plan then.
On Fri, Jul 4, 2014 at 1:42 PM, Victor Stinner
wrote:
> 2014-07-04 16:52 GMT+02:00 Guido van Rossum :
> > But wouldn't keeping the traceback (on cancel) be just as detrimental as
> > keeping the callback/args?
>
> _source_traceback
But wouldn't keeping the traceback (on cancel) be just as detrimental as
keeping the callback/args?
On Fri, Jul 4, 2014 at 4:23 AM, Victor Stinner
wrote:
> Hi,
>
> 2014-07-04 1:19 GMT+02:00 Guido van Rossum :
> > There's also the solution that was proposed
celled, but
I'm not sure how common that use case is (the OP specifically mentioned
timeouts).
I've got a feeling that occasionally it might be useful to have the
callback+args show up in a handler's repr(), even if it is cancelled, but
I'm not sure how valuable that is i
ass variable can be modified before event loops are created, to
> > modify the factory on all threads. Or it can be modified on a single
> > event loop, even after the event loop creation.
> >
> > The limitation is that all libraries must agree on the task factory.
> > For example, greenio wants to use greenio.GreenTask whereas Pulsar
> > wants to use
> >
> > Victor
>
--
--Guido van Rossum (python.org/~guido)
ive any data. It can keep the socket open
> to write more data if protocol.eof_received() is False, but it doesn't
> call sock.shutdown(socket.SHUT_RD).
>
> Is there a reason for not calling sock.shutdown(socket.SHUT_RD)? If
> yes, it would be nice to document it in a comment.
&
patching the
> > base_events._check_already_resolved method, and I think think there
> should
> > be a more beautiful way to do this in Python.
> >
> > Thank you for your consideration.
> >
> >
>
>
>
> --
> Thanks,
> Andrew Svetlov
>
--
--Guido van Rossum (python.org/~guido)
complex
> to use by average developer).
> Thus at least for now (at least for next couple months) better to keep
> aiohttp code small and simple.
> If some volunteer will invest own time in trollius support after
> stabilization of aiohttp API -- welcome!
>
> On Tue, Jun 3, 2014
gt; Bugfix: Python 3.4 => Python 3.5 => Tulip => Trollius
>
> I don't think that Tulip should have minor release just for bugfixes,
> it would be a pain to maintain.
>
> What do you think?
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
ulip on Python 3.3
> import asyncio
> except ImportError:
> # Use Trollius on Python <= 3.2
> import trollius as asyncio
> ---
>
> Using such code, your application can also use modules supporting only
> asyncio like aiohttp when running on Python 3.3+. (I'm not sure that
> it's very useful since you need to have a "fallback" on Python 2.)
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
27;m also curious what
Twisted Deferreds do in this case -- if an outer Deferred is waiting for an
inner Deferred and the inner Deferred is cancelled, is the outer one
considered cancelled too?
On Fri, May 30, 2014 at 9:20 AM, Jason Tackaberry wrote:
> On 14-05-29 02:05 PM, Guido van Ros
On Wed, May 28, 2014 at 6:18 PM, Jason Tackaberry wrote:
> On 14-05-28 07:34 PM, Guido van Rossum wrote:
>
> I have a feeling that what's really going on here is a subtle bug in
> Task._step(): when the coroutine raises CancelledError, it *always* assumes
> this means the
On Tue, May 27, 2014 at 9:49 PM, Jason Tackaberry wrote:
>
> On 14-05-27 11:03 AM, Guido van Rossum wrote:
>
> A cancellation, however, is different. It is initiated by the *consumer*
> to indicate that it is no longer interested in the result.
>
>
> I think out of
nt of data (through
exception attributes), compared to the single "cancelled" bit that we
currently have. Can't you create an object that is shared between consumer
and producer where the consumer can indicate the difference between soft
and hard aborts?
On Tue, May 27, 2014 at 8:03 AM
On Mon, May 26, 2014 at 6:36 PM, Jason Tackaberry wrote:
>
> On 14-05-26 06:21 PM, Guido van Rossum wrote:
>
> Re 1: I'm not sure I follow. Have you found specific code in Tulip that
> suppresses logging of cancellation? If so, are you sure you are hitting
> this code?
and up the stack. The custom exception would need to subclass
> CancelledError.
>
> Thoughts? I am happy to submit a patch if there's agreement that this
> is a good idea. (Obviously I think it is. :))
>
>
> Thanks!
> Jason.
>
> [1] http://api.freevo.org/kaa-base/index.html
> [2]
> http://api.freevo.org/kaa-base/async/inprogress.html#kaa.InProgress.abort
>
--
--Guido van Rossum (python.org/~guido)
type, not
> trollius.Future
>
> - When using an asyncio event loop, Trollius coroutine complains that
> the Return object was used without raise. The Trollius event loop sets
> the raised attribute of Return, whereas the asyncio loop doesn't.
>
> - I didn't spe
hu, May 22, 2014 at 2:55 AM, Phil Schaf wrote:
> Am Donnerstag, 22. Mai 2014 03:05:43 UTC+2 schrieb Guido van Rossum:
>
>> Ah, I think I understand. You can probably solve this by having a Future
>> and making the callback set the Future's result. Perhaps you should als
uld get done,
> and then the server should wait for the next message.
>
> this would work if, instead of job.do_things(), i would use a loop and
> yield inside of it. but that’s impossible:
>
> this is a simplified version.
>
> in reality, the third party job does thi
force the 3rd party code to yield sometimes?
>
> Best, philipp
>
--
--Guido van Rossum (python.org/~guido)
On Tue, May 20, 2014 at 6:07 AM, Victor Stinner wrote:
> 2014-05-19 19:21 GMT+02:00 Guido van Rossum :
> > I've released a matching source release of asyncio (a.k.a. Tulip, but you
> > have to search PyPI for "asyncio"). This is only relevant if you want to
> use
There is now a Wheel file for 32-bit Python 3.3 as well.
Please test it and let me know if it works!
--Guido
On Mon, May 19, 2014 at 10:21 AM, Guido van Rossum wrote:
> I've released a matching source release of asyncio (a.k.a. Tulip, but you
> have to search PyPI for "as
ange log per se, but you can see the revision history
here: https://code.google.com/p/tulip/source/list
I don't have a Wheel file for Windows yet, once I have uploaded it I will
post again here.
--Guido
On Mon, May 19, 2014 at 7:52 AM, Guido van Rossum wrote:
> It also has a slew of mi
elog:
> https://docs.python.org/3.4/whatsnew/changelog.html
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
hough: how do you feel about ctypes? I see that's it's
> occasionally used in stdlib, but given that you went out of your way to
> create the _overlapped module for asyncio, would it be acceptable to use
> ctypes for timeGetTime?
>
> Mathias
>
> Den søndag den 18. maj 2014
Glad I could help! And yes, we could use more examples...
On Sat, May 17, 2014 at 6:23 PM, Dan McDougall wrote:
> On Saturday, May 17, 2014 5:43:34 PM UTC-4, Guido van Rossum wrote:
>>
>> The reason the reader/writer don't expose their FD is that there's
>> a
if asyncio becomes the go-to eventloop for all Python
> things.
>
Yes, that's my hope too!
> This is probably why I'm very keen on having a good default
> implementation. For all platforms. ;-)
>
> Cheers,
> Mathias
>
> Den lørdag den 17. maj 2014 23.29.30 UTC+2
away some of the (relative) elegance of using asyncio in the first place.
Also,
Let me play with these ideas some more. It would be a neat demo if it
worked.
--Guido
On Sat, May 17, 2014 at 4:40 PM, Guido van Rossum wrote:
> I take back my speculation from last night; Dino's code did o
ed in, but
also pretty different; I will try to understand the differences and maybe I
can help you. (You also need a Holmes.txt file; this one seems to work:
http://www.gutenberg.org/cache/epub/1661/pg1661.txt.)
On Fri, May 16, 2014 at 9:40 PM, Guido van Rossum wrote:
> I suspect it never wo
riptor... Or perhaps I'm missing
> something. Is there a "better way" to handle this kind of thing?
>
> If I did the same thing with subprocess.Popen() the resulting proc.stdout
> and proc.stderr will have fileno() methods that can be passed to
> loop.add_reader(). I assume there was a good reason why the same
> functionality was not added to asyncio.create_subprocess_shell()?
>
--
--Guido van Rossum (python.org/~guido)
>>>> For my application, I can probably subclass the eventloop and switch
>>>> out the timer implementation, but ideally, this should be fixed upstream
>>>> somehow.
>>>> I never had this issue with Twisted, even though I think Twisted uses
>>&g
rsonally, I've always found a combination of timeGetTime() and
>>> timeBeginPeriod(1) to yield a very stable timer on Windows (especially for
>>> games), but perhaps you have greater insight into the issue.
>>>
>>> Thanks for the help! Is there any chance thi
changed.
>
> I'm not sure that I understood the design. asyncio event loop and Tk
> main loop are both running in the same thread? The code uses at least
> two pools of threads.
>
> It looks like the Tk loop must run in the main loop. Why not using a
> standard asyncio event loop in a dedicated thread with
> call_soon_threadsafe()?
>
> Victor
>
--
--Guido van Rossum (on iPad)
ot being logged, of course).
>
> Is this a bug in my LoopingCall class, or is it a problem with the
> eventloop timer granularity?
>
> This is using the asyncio release found in stdlib on Python 3.4, by the
> way.
>
> Thanks for the help!
>
>
--
--Guido van Rossum (on iPad)
This is now fixed in the Tulip repo and in the CPython 3.4 and default
branches. Akira, thanks for reporting this issue!
aiohttp) with such loop?
>
> I should play with such setup to see how it can work :-)
>
> A "trollius" module name would avoid confusion between Tulip (yield
> from) and Trollius (yield).
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
101 - 200 of 433 matches
Mail list logo
