On Sat, Dec 3, 2016 at 1:26 AM, Frank Millman wrote:
> Then Twisted made a strong case for an asynchronous approach. One of their
> claims (which I have no reason to doubt) was that, because each user
> 'session' spends most of its time waiting for something - keyboard input,
> reply from database
"Frank Millman" :
> Then Twisted made a strong case for an asynchronous approach. One of
> their claims (which I have no reason to doubt) was that, because each
> user 'session' spends most of its time waiting for something -
> keyboard input, reply from database, etc - their approach allows
> hund
"Steve D'Aprano" wrote in message
news:58417e2d$0$1612$c3e8da3$54964...@news.astraweb.com...
My first impressions on this is that we have a couple of good models for
preemptive parallelism, threads and processes, both of which can do
everything that concurrency can do, and more, and both of whi
Steve D'Aprano :
> py> await x
> File "", line 1
> await x
> ^
> SyntaxError: invalid syntax
"await" is only allowed inside a coroutine.
> So why do we need asyncio? What is it actually good for?
Asyncio is a form of cooperative multitasking. It presents a framework
of "fake thr
On Thu, 1 Dec 2016 06:53 pm, Christian Gollwitzer wrote:
> well that works - but I think it it is possible to explain it, without
> actually understanding what it does behind the scences:
>
> x = foo()
> # schedule foo for execution, i.e. put it on a TODO list
>
> await x
> # run the TODO list u
On Thu, Dec 1, 2016 at 12:53 AM, Christian Gollwitzer wrote:
> well that works - but I think it it is possible to explain it, without
> actually understanding what it does behind the scences:
>
> x = foo()
> # schedule foo for execution, i.e. put it on a TODO list
This implies that if you never a
Am 30.11.16 um 22:07 schrieb Gregory Ewing:
Chris Angelico wrote:
That's because you're not actually running anything concurrently.
Yes, I know what happens and why. My point is that for
someone who *doesn't* know, simplistic attempts to
explain what "await" means can be very misleading.
The
Gregory Ewing :
> My point is that for someone who *doesn't* know, simplistic attempts
> to explain what "await" means can be very misleading.
>
> There doesn't seem to be any accurate way of summarising it in a few
> words. The best we can do seems to be to just say "it's a magic word
> that you h
Terry Reedy :
> On 11/30/2016 7:53 AM, Chris Angelico wrote:
>
>> I also think that everyone should spend some time writing
>> multithreaded code before switching to asyncio. It'll give you a
>> better appreciation for what's going on.
>
> I so disagree with this. I have written almost no thread c
Chris Angelico wrote:
That's because you're not actually running anything concurrently.
Yes, I know what happens and why. My point is that for
someone who *doesn't* know, simplistic attempts to
explain what "await" means can be very misleading.
There doesn't seem to be any accurate way of sum
On Wed, Nov 30, 2016 at 10:58 AM, Chris Angelico wrote:
> On Thu, Dec 1, 2016 at 5:54 AM, Terry Reedy wrote:
>> On 11/30/2016 7:53 AM, Chris Angelico wrote:
>>
>>> I also think that everyone should spend some time writing
>>> multithreaded code before switching to asyncio. It'll give you a
>>> be
On Thu, Dec 1, 2016 at 5:54 AM, Terry Reedy wrote:
> On 11/30/2016 7:53 AM, Chris Angelico wrote:
>
>> I also think that everyone should spend some time writing
>> multithreaded code before switching to asyncio. It'll give you a
>> better appreciation for what's going on.
>
>
> I so disagree with
On 11/30/2016 7:53 AM, Chris Angelico wrote:
I also think that everyone should spend some time writing
multithreaded code before switching to asyncio. It'll give you a
better appreciation for what's going on.
I so disagree with this. I have written almost no thread code but have
successfully
On Wed, Nov 30, 2016 at 11:40 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> From the point of view of
>> the rest of Python, no. It's a sign saying "Okay, Python, you can
>> alt-tab away from me now".
>
>
> The problem with that statement is it implies that if
> you omit the "await", then
Chris Angelico wrote:
From the point of view of
the rest of Python, no. It's a sign saying "Okay, Python, you can
alt-tab away from me now".
The problem with that statement is it implies that if
you omit the "await", then the thing you're calling
will run uninterruptibly. Whereas what actually
On Tuesday 29 November 2016 14:21, Chris Angelico wrote:
"await" means "don't continue this function until that's done". It
blocks the function until a non-blocking operation is done.
That explanation gives the impression that it's some
kind of "join" operation on parallel tasks, i.e. if
you d
On Wed, 30 Nov 2016 05:41 am, Ian Kelly wrote:
> You mean how do you create something that can be awaited that doesn't
> await something else in turn? With a Future.
>
> import asyncio
>
> class Awaitable(asyncio.Future):
> def wake_up_later(self):
> asyncio.get_event_loop().call_later(3,
On Mon, Nov 28, 2016 at 10:42 PM, Chris Angelico wrote:
> On Tue, Nov 29, 2016 at 4:13 PM, Paul Rubin wrote:
>>
>> I haven't gotten my head around Python asyncio and have been wanting
>> to read this:
>>
>>http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
>
> It's talking a lot ab
Gregory Ewing :
> All the terminology around async/await is inherently confusing and
> counterintuitive, IMO. I'm disappointed that we've ended up here.
I think the conceptual mess can be clarified over time. Coroutines are
essentially threads. Why Python needs two threading implementations is
que
On Tue, Nov 29, 2016 at 4:32 PM, Steven D'Aprano
wrote:
> On Tuesday 29 November 2016 14:21, Chris Angelico wrote:
>
>> On Tue, Nov 29, 2016 at 1:23 PM, Steve D'Aprano
>> wrote:
>>> This is confusing: why is this awaiting something inside an async function?
>>> Doesn't that mean that the await as
On Tue, Nov 29, 2016 at 4:13 PM, Paul Rubin wrote:
>
> I haven't gotten my head around Python asyncio and have been wanting
> to read this:
>
>http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
It's talking a lot about how we got here, which isn't all necessary if
you just want to
On Tuesday 29 November 2016 14:21, Chris Angelico wrote:
> On Tue, Nov 29, 2016 at 1:23 PM, Steve D'Aprano
> wrote:
>> This is confusing: why is this awaiting something inside an async function?
>> Doesn't that mean that the await asyncio.gather(...) call is turned
>> blocking?
>
> "await" means
Chris Angelico writes:
> Asynchronous I/O is something to get your head around I'd much
> rather work with generator-based async functions...
I haven't gotten my head around Python asyncio and have been wanting
to read this:
http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
To be fair, in other languages, such as C# or C++ with similar mechanisms,
if you don't ask for the result from an async or future task, there's no
guarantee the async task will be executed at all unless (or until) you ask
for the result. C++'s futures even give an explicit flag indicating you
want
On Tue, Nov 29, 2016 at 3:16 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> "await" means "don't continue this function until that's done". It
>> blocks the function until a non-blocking operation is done.
>
>
> However, *not* using 'await' doesn't mean the operation
> will be done without
Chris Angelico wrote:
"await" means "don't continue this function until that's done". It
blocks the function until a non-blocking operation is done.
However, *not* using 'await' doesn't mean the operation
will be done without blocking. Rather, it won't be done
at all (and is usually an error, b
On Mon, Nov 28, 2016 at 6:48 AM, Steve D'Aprano
wrote:
> What am I doing wrong?
Give yourself a bit more to debug with, since you're going to want to
do something with the result your expensive calculation anyway:
import asyncio
class Counter:
def __init__(self, i):
self.count = 10
On Tue, Nov 29, 2016 at 1:23 PM, Steve D'Aprano
wrote:
> This is confusing: why is this awaiting something inside an async function?
> Doesn't that mean that the await asyncio.gather(...) call is turned
> blocking?
"await" means "don't continue this function until that's done". It
blocks the func
Take a look at Doug Hellmann's example using multiprocessing at
https://pymotw.com/2/multiprocessing/basics.html You should be able to
substitute the count down example directly into the first example.
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 29 Nov 2016 12:03 am, Chris Angelico wrote:
> On Mon, Nov 28, 2016 at 11:48 PM, Steve D'Aprano
> wrote:
>> When I try running that, I get no output. No error, no exception, the
>> run_until_complete simply returns instantly.
>
> When I do, I get this warning:
>
> asynctest.py:17: Runtim
On Tue, Nov 29, 2016 at 11:20 AM, Steve D'Aprano
wrote:
> On Tue, 29 Nov 2016 02:53 am, Ian Kelly wrote:
>
>> In order for the coroutines to actually do anything, you need to
>> schedule them in some way with the event loop. That could take the
>> form of awaiting them from some other coroutine, o
On Tue, 29 Nov 2016 02:53 am, Ian Kelly wrote:
> In order for the coroutines to actually do anything, you need to
> schedule them in some way with the event loop. That could take the
> form of awaiting them from some other coroutine, or passing them
> directly to loop.run_until_complete or event_l
On Mon, Nov 28, 2016 at 5:48 AM, Steve D'Aprano
wrote:
> Let's pretend that the computation can be performed asynchronously, so that
> I can have all five Counter objects counting down in parallel. I have this:
>
>
> import asyncio
>
> class Counter:
> def __init__(self):
> self.count
On Mon, Nov 28, 2016 at 11:48 PM, Steve D'Aprano
wrote:
> When I try running that, I get no output. No error, no exception, the
> run_until_complete simply returns instantly.
When I do, I get this warning:
asynctest.py:17: RuntimeWarning: coroutine 'Counter.count_down' was
never awaited
obj.co
34 matches
Mail list logo
