> for any IO-bound call with a variable time where async isn't an option
(either because it's not available, standardized, widespread, etc.), I'd
advise using loop.run_in_executor()/to_thread() preemptively.
Clarification: this pretty much applies to any non-async IO-bound call that
can block the
> IOW the solution to the problem is to use threads. You can see here
why I said what I did: threads specifically avoid this problem and the
only way for asyncio to avoid it is to use threads.
In the case of the above example, I'd say it's more so "use coroutines by
default and threads as needed"
On Sun, Jun 14, 2020 at 2:16 PM Kyle Stanley wrote:
>
> > If
> you're fine with invisible context switches, you're probably better
> off with threads, because they're not vulnerable to unexpectedly
> blocking actions (a common culprit being name lookups before network
> transactions - you can conn
On 14/06/20 1:42 pm, Chris Angelico wrote:
Hmm, I think I see what you mean. So awaiting it would be "spam(123)"
No, it would still be "await spam(123)". It's just that you wouldn't
be able to separate the await from the call, so this wouldn't be
allowed:
a = spam(123)
await a
Incidenta
> If
you're fine with invisible context switches, you're probably better
off with threads, because they're not vulnerable to unexpectedly
blocking actions (a common culprit being name lookups before network
transactions - you can connect sockets asynchronously, but
gethostbyname will block the curr
On Sun, Jun 14, 2020 at 11:29 AM Greg Ewing wrote:
>
> On 14/06/20 12:05 pm, Chris Angelico wrote:
> > On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing
> > wrote:
> >> Likewise, it's legitimate to create an awaitable
> >> object and then await it later.
> >>
> >> (Personally I think it *shouldn't* be
On 14/06/20 12:05 pm, Chris Angelico wrote:
On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing wrote:
Likewise, it's legitimate to create an awaitable
object and then await it later.
(Personally I think it *shouldn't* be legitimate to do that in
the case of await, but Guido thinks otherwise, so it is
On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing wrote:
> But this would require reading the programmer's mind, because it's
> quite legitimate to create an iterator and keep it around to be
> yielded from later. Likewise, it's legitimate to create an awaitable
> object and then await it later.
>
> (Per
Allowing the 'await' keyword to be omitted would also present some
semantic and implementation difficulties. The mechanism behind
'await' is essentially the same as 'yield from', so you're more
or less asking for 'yield from' to be automagically applied to
the result of an expression.
But this wo
> Your project is fundamentally about instantiating processes?
Yes, that and spawning other subprocesses depending on the outcome of the
previous one, sometimes concurrently per-host but mostly sequentially, and
clearly most of the time will be spent waiting for suprocesses because all
my commands
On Sat, Jun 13, 2020 at 8:14 PM J. Pic wrote:
>
> I'm not sure I should rewrite my asyncio code to threading, I'll just keep
> going asyncio, maybe one day it'll be possible to get the best of both worlds
> ...
>
> On #python they generally tell me that the extra syntax is worth it because
> of
I'm not sure I should rewrite my asyncio code to threading, I'll just keep
going asyncio, maybe one day it'll be possible to get the best of both
worlds ...
On #python they generally tell me that the extra syntax is worth it because
of the internal details, that rewriting to threads does not seem
On 13/06/20 3:02 pm, Steven D'Aprano wrote:
Coroutines are lighter weight than threads because they don't need all
the machinary to pre-emptively run threads in parallel; threads are
lighter weight than processes because they don't need to be in separate
memory spaces enforced by the OS.
Well,
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 coroutines,
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.
Of
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, suc
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. Tel
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
abo
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 test
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
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
23 matches
Mail list logo
