Thank you for all your answers. They were all very instructive to me.
However, after further investigation, I feel that I have made a mistake when
putting this topic on the table.
When walrus operator was discussed, it was proposed to restrict assignment
expressions to if, elif, and while state
I agree that is counter to the basic philosophy, though there are potential use
cases where it may be unavoidable to use threads. It seems the best solutions
when it is then are to use run_in_executor, which automatically handles the
waking up of the loop. While the Queue object doesn't work w
Thanks for all of your feedback. I've updated the PEP to explain the current
restrictions up front, and removed the section covering the interaction between
decorators and binary @ operations.
My overall impression is that there were no issues with the substance of the
PEP itself, just its pres
> I agree that is counter to the basic philosophy, though there are
potential use cases where it may be unavoidable to use threads. It seems
the best solutions when it is then are to use run_in_executor, which
automatically handles the waking up of the loop.
While this doesn't provide an immediat
Oops, I forgot to start the thread in the above example for
compute_something(), ``th.start()`` should go right after initializing the
thread but before the try-finally block
On Thu, Feb 13, 2020 at 6:15 PM Kyle Stanley wrote:
> > I agree that is counter to the basic philosophy, though there are
