On Sun, Aug 18, 2013 at 2:32 AM, Guido van Rossum <gu...@python.org> wrote:
I think Go's strategy is great... for Go. It is aided by the compiler, though, and it's hard to see how the idea would carry properly to Python. If you want to voluntarily use Go's *style*, you can use the Queue class (either the threaded variety or Tulip's version). IIRC it's not possible to set the queue size to zero (passing 0 means unlimited buffer size) but we could add an UnbufferedQueue subclass for that purpose if there's demand.Yes, Go's strategy fits very well in the overall language design. From an engineering point of view (not a stylistic point a view), what makes difficult to carry this strategy (goroutines communicating through channels with implicit context switching) properly to Python? I'm not sure to understand why the compiler makes this easier in Go.PS. Next time can you start a new topic rather than reviving such an old thread?
Sorry for this. I thought it was on topic. Next time I'll start a new thread :)
I'm starting a new one now named "Why not goroutines".To answer why it's not easy to add goroutines to Python, it would actually be very easy if you mapped them into threads.
To address this you can use greenlets, but we already went over that in the previous thread. :-)
And without the compiler recognizing goroutines and channel operations, you still are required to remember to use the proper API voluntarily, you won't have Go's select syntax, and so on.
Basically, what you can do without help from the compiler is not very interesting. If you want a more specific answer, you'll have to propose a specific example of a program using goroutines that you find elegant, and I'd be happy to try and figure out how it could be translated into Python.