Asyncio -- delayed calculation

[Nathan Ernst]

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 the task to be executed on the current thread, but deferred until the
result is asked for. I'm sure the people on the standards committee had a
rationale for this, but I see only marginal utility for that use case
(maybe such as a cancellable expensive calc?). Seems like "I might need the
result of this calc down the road, but I don't need it currently, so I'll
just kick the can down the road.". I'm not aware of a mechanism to make C#
behave that way, but I know it's possible that tasks will not execute until
they're asked for their result, but I don't know that it is 100%
deterministic.

To be honest, I think async/await stile programming is so new that there's
not a lot of good material about how to properly use it (as far as both
when and how). The limit of my experience has been in C# dealing with web
requests, where the usage is basically, I'm going to need this data, so
I'll fire off the async request for it, and I've got a lot of work I can do
before I need the result, so lets do that, until I need to wait (await) for
the result of that request before I can proceed any further. It can be
useful, but it is a new, completely different paradigm and methodology to
wrap ones head around. I've used it for about 2 years in C# land, and I
still don't know that I'm doing it right. I've not done any async/await in
Python space, but I'm eager to learn and try, when it may be appropriate,
But, most of my current use cases don't require it.

On Mon, Nov 28, 2016 at 10:37 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Tue, Nov 29, 2016 at 3:16 PM, Gregory Ewing
> <greg.ewing at canterbury.ac.nz> 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 blocking. Rather, it won't be done
> > at all (and is usually an error, but there's no way for
> > the implementation to detect it at the time).
> >
> > I don't blame Steve for being confused. All the
> > terminology around async/await is inherently confusing
> > and counterintuitive, IMO. I'm disappointed that we've
> > ended up here.
>
> Asynchronous I/O is something to get your head around. As someone who
> teaches both JavaScript and Python, I've run into this quite a bit,
> and frankly, callbacks may be easy to explain at a concrete level, but
> I'd much rather work with generator-based async functions (which JS is
> getting soon too). The best way to think about it IMO is a "process"
> that does blocking calls, and which the "system" can multitask away
> from any time it's blocked. Your function awaits something, but Python
> doesn't.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>