[Python-ideas] channel (synchronous queue)

[Guido van Rossum]

On Sun, Feb 19, 2012 at 10:08 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 19 February 2012 18:01, Sturla Molden <sturla at molden.no> wrote:
>> It is ~20 lines
>> of trivial code with objects already in the standard library. Well, one
>> could say the same thing about a queue too (it's just deque and a lock), but
>> it is very useful and commonly used, so there is a difference.
>
> FWIW, I wouldn't have got this code right if I'd tried to write it.
> I'd have missed a lock or something. So it's possible that having it
> in the standard library avoids people like me writing buggy
> implementations.

It would also encourage using it as an interface between libraries
with different authors, which would not happen if it was just a recipe
-- every author would implement their own version of the recipe, and
they would not be API-compatible even if they did the same thing. Many
of the existing primitives in threading.py are very simple
combinations of the basic Lock; but that doesn't make it less valuable
to have them.

Also, writing a performant Channel implementation for multiprocessing
would hardly be a trivial job; it seems primitives don't make it into
multiprocessing without first existing in threading.py.

So all this suggests to me that there is no great harm in adding
threading.Channel and it might open up some interesting new approaches
to synchronization.

That said, it certainly isn't a panacea; e.g. some Go examples written
using Channels are better done with coroutines instead of threads in
Python. (IIUC Go intentionally blurs the difference, but that's not
given to Python.)

> On the other hand, I can't imagine ever needing to
> use a channel object like this, so it would probably be worth having
> some real-world use cases to justify it.

I think Matt Joiner's original post hinted at some. Matt, could you
elaborate? We may be only an inch away from getting this into the
stdlib...

-- 
--Guido van Rossum (python.org/~guido)