On 15.04.17 01:42, Greg Ewing wrote:
Serhiy Storchaka wrote:
but should not affect performance since locking is used only when you
faced with a generator running in other thread.
I don't think that's true, because the first thread to use a
generator has to lock it as well. And even if there is
Serhiy Storchaka wrote:
but should not
affect performance since locking is used only when you faced with a
generator running in other thread.
I don't think that's true, because the first thread to use a
generator has to lock it as well. And even if there is only
one thread in existence when __
Enums are great. They allow you cleanly define a set of statically defined
options.
One way that I've found myself using enums recently is for dispatching (as
keys in a dictionary) between different interchangeable functions or
classes. My code looks something like this:
from enum import Enum
de
When use a generator from different threads you can get a ValueError
"generator already executing". Getting this exception with the single
thread is a programming error, it in case of different threads it could
be possible to wait until other thread finish executing the generator.
The generator
On 14 April 2017 at 04:20, Steven D'Aprano wrote:
> Long ago, when the operator module was first introduced, there was a
> much stronger correspondence between the operator.__dunder__ functions
> and dunder methods. But I think that correspondence is now so weak that
> we should simply treat it as
