> An await outside async def, would map to awaitable.run().
> A call to baz() would thus create a coroutine foo(), and then run() it.
-1. The `await` expression already has a well-defined purpose of suspending
the coroutine it's used within until the awaitable is completed. I think
this change
On Sat, Jun 13, 2020 at 02:09:53PM +1200, Greg Ewing wrote:
> On 13/06/20 9:37 am, Chris Angelico wrote:
> >If you don't care where the context
> >switches happen and just want everything to behave sanely by default,
> >use threads, not coroutines.
>
> There are other reasons for using
While I agree that we should avoid telling people to "just use threads", I
think Chris was instead informing the OP that their desired behavior is
already present in threads, and if they don't want to be concerned at all
about context switching, OS threads should be considered as an alternative.
On Sat, Jun 13, 2020 at 12:11 PM Greg Ewing wrote:
>
> On 13/06/20 9:37 am, Chris Angelico wrote:
> > If you don't care where the context
> > switches happen and just want everything to behave sanely by default,
> > use threads, not coroutines.
>
> There are other reasons for using coroutines,
On 13/06/20 9:37 am, Chris Angelico wrote:
If you don't care where the context
switches happen and just want everything to behave sanely by default,
use threads, not coroutines.
There are other reasons for using coroutines, such as the fact that
they're very lightweight compared to threads.
> Could you be more specific about these tools? They sound like they
may be what Celelibi is looking for. Just a list of APIs (even just a
few core items) would likely point them at the right parts of the
doc.
Sorry if it wasn't clear, but by "interoperability tools", I was referring
to the API
On 2020-06-12 5:47 p.m., J. Pic wrote:
Hi all,
Currently, you can not use await outside an async function, the
following code:
async def lol():
return 'bar'
def test():
return await lol()
print(test())
Will fail with: SyntaxError: 'await' outside async function
Of course,
> Do you mean that it's not possible to implement this at the syntax level
> because we don't know until runtime if this is being call from a loop (async
> calling sync code) ?
No. I'm saying you should clarify the semantics you want if you have
if your sync `test()` is called from within an
> I do think there is some case for non rentrency and nested loop where
what you define here would block an outer loop, but most people
suggesting what you ask actually want re-entrency, which is not
possible there.
Do you mean that it's not possible to implement this at the syntax level
because
That switch means other things can now occur. You have to know that when
you yield your coroutine other things may mutate state, which means you now
need to check that no previous assumptions have become invalid. Event loops
typically being single-threaded means you don't need to lock and worry
On Sat, Jun 13, 2020 at 7:29 AM J. Pic wrote:
>
> I mean, if it pauses because of some blocking IO and switches to another
> coroutine, that's just a BIG win ... I have hard times trying to figure how
> that signal could be useful to me as a developer. On the other hand, I have
> to (await
I mean, if it pauses because of some blocking IO and switches to another
coroutine, that's just a BIG win ... I have hard times trying to figure how
that signal could be useful to me as a developer. On the other hand, I have
to (await test()).bar ...
___
Thank you for your comments,
In my experience, 99.9% of the time I don't want to do_something_else()
before I want to await do_something().
I could as well change this code:
foo.bar
To:
foo.__getattribute__('bar')
This would signal that I'm calling the __getattribute__ function.
But the
The use of `await` is on purpose to signal to you as a developer that the
event loop may very well pause at that point and context switch to another
coroutine. Take that away and you lose that signal. You also would never
know from your code whether you need to have an event loop running or not
to
See some of the previous discussions on asyncio reentrancy.
https://mail.python.org/pipermail/async-sig/2019-March/thread.html
I do think there is some case for non rentrency and nested loop where
what you define here would block an outer loop, but most people
suggesting what you ask actually
On Sat, Jun 13, 2020 at 7:02 AM J. Pic wrote:
>
> Hi all,
>
> Just wonder what it would look like if coroutines where awaited by default,
> you would only have to use "noawait" when you do *not* want to await a
> coroutine ?
>
import threading :)
ChrisA
Hi all,
Just wonder what it would look like if coroutines where awaited by default,
you would only have to use "noawait" when you do *not* want to await a
coroutine ?
async def test():
return do_something()
# it's awaited here by default: we get the result and not a coroutine
result1
Hi all,
Currently, you can not use await outside an async function, the following
code:
async def lol():
return 'bar'
def test():
return await lol()
print(test())
Will fail with: SyntaxError: 'await' outside async function
Of course, you can use asyncio.run and then it works
Yes, that's reasonable, and the PEG parser supports this (just put the
`del_stmt` rule before the `expression` rule).
I'm not sponsoring your proposal though -- you're going to have to convince
other core devs (and ultimately the Steering Council) that this is worth
it. Once you have a core dev
Yes, it would mean that, which is particularly nasty considering the fact
that `_` in python and `Out` in IPython would then acquire the very
reference that was being deleted.
I think that my proposed change would be unacceptable without
addressing this problem.
To resolve this, `del` could be
On Fri, Jun 12, 2020 at 4:55 AM Eric Wieser
wrote:
> > He thought that the change of del he proposed will give him that
> behavior, but this is not true.
>
> Unless I'm forgetting part of the conversation, that's not true. Note that
> the numpy patch is merged. Today, you get the optimization
On Thu, 12 Mar 2020 at 14:09, Paul Moore wrote:
>
> On Thu, 12 Mar 2020 at 16:57, Eric Wieser wrote:
> >
> > It looks like actually this can be be built as a function today:
> >
> > def move(name):
> > return inspect.currentframe().f_back.f_locals.pop(name)
> >
> > Which works as
> He thought that the change of del he proposed will give him that behavior,
> but this is not true.
Unless I'm forgetting part of the conversation, that's not true. Note that the
numpy patch is merged. Today, you get the optimization with `z = a + b + c +
d`. What you don't get is the same
23 matches
Mail list logo
