On Wed, Jun 24, 2015 at 10:28 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 24/06/15 07:01, Eric Snow wrote:
Well, perception is 9/10ths of the law. :) If the multi-core problem is already solved in Python then why does it fail in the court of public opinion. The perception that Python lacks a good multi-core story is real, leads organizations away from Python, and will not improve without concrete changes.
I think it is a combination of FUD and the lack of fork() on Windows. There is a lot of utterly wrong information about CPython and its GIL.
Thanks for a clear summary of the common misunderstandings. While I agreed with your points, they are mostly the same things we have been communicating for many years, to no avail. They are also oriented toward larger-scale parallelism (which I don't mean to discount). That makes it easier to misunderstand. Why? Because there are enough caveats and performance downsides (see Dave Beazley's PyCon 2015 talk) that most folks stop trying to rationalize, throw their hands up, and say "Python concurrency stinks" and "you can't *really* do multicore on Python". I have personal experience with high-profile decision makers where this is exactly what happened, with adverse consequences to support for Python within the organizations. To change this perception we need to give folks a simpler, performant concurrency model that takes advantage of multiple cores. My proposal is all about doing at least *something* that makes Python's multi-core story obvious and undeniable. *That* is my entire goal with this proposal. Clearly I have opinions on the best approach to achieve that in the 3.6 timeframe. :) However, I am quite willing to investigate all the options (as I hope this thread demonstrates). So, again, thanks for the feedback and insight. You've provided me with plenty of food for thought. -eric