Live data from Hacker News

A green threading library with true concurrency for Python

github.com

1–10 of 40 posts

Re: A green threading library with true concurrency for Python

#4
post #3

I don't really get what advantage this gives me beyond using gevent. There's still no parallelism. The readme describes it as "A solution to concurrency," but I already get that using gevent. Is it just to improve communication between green threads?

Fewer explicit yields & no monkey patching necessary for IO performing libraries.

Re: A green threading library with true concurrency for Python

#6

> Conpig threads still can only run on one core of a processor. The disillusionment caused by having so many options for non-parallel "concurrency" in Python is, I believe, feeding the high defection rate from Python to Go.

The lack of options for parallel (and non-parallel) concurrency is, along with other things, feeding the high defection rate to many other languages.

Re: A green threading library with true concurrency for Python

#7
post #2

Since this is a very new project, it is a good time to suggest that you abide by PEP8 (e.g., no 'waitAll') since this would be widely appreciated, and is not easy to fix later on.

waitAll gone. Before I put it in any package managers it will get style guided. This is currently on version -1.0.0.

Re: A green threading library with true concurrency for Python

#8
post #6

> Conpig threads still can only run on one core of a processor. The disillusionment caused by having so many options for non-parallel "concurrency" in Python is, I believe, feeding the high defection rate from Python to Go.

The lack of options for parallel (and non-parallel) concurrency is, along with other things, feeding the high defection rate to many other languages.

We've had processes, threads and greenlets for a while now... if anything the problem isn't that there are no options, but too many options that require understanding to choose and apply.

Many of the people complaining about this issue don't have a demonstrated problem and could try any simple approach first (if the point is not just to slam Python in favor of something else, from the beginning).

Re: A green threading library with true concurrency for Python

#10
post #3

I don't really get what advantage this gives me beyond using gevent. There's still no parallelism. The readme describes it as "A solution to concurrency," but I already get that using gevent. Is it just to improve communication between green threads?

It appears to add some amount of Python-bytecode level preemption to gevent, which allows you to hopefully avoid some of the pathological cases of cooperative scheduling. Said pathological cases are only a matter of scale... if your program becomes large enough, you will hit them, eventually.

That said, with no offense intended to mirman, I'd really hesitate before using this for anything serious enough to reach that scale in the first place. Gevent, frankly, visibly pushes Python to the limits (and occasionally a bit beyond), trying to also tack on some preemption on an environment not fundamentally expecting it would scare me another notch.

Post reply on HN