On Fri, 10 Feb 2012 03:16:00 +0800 Matt Joiner <anacrolix@gmail.com> wrote:
If threading is the only acceptable concurrency mechanism, then Python is the wrong language to use. But you're also not building scaleable systems, which is most of where it really matters. If you're willing to consider things other than threading - and you have to if you want to build scaleable systems - then Python makes a good choice. Yes but core Python doesn't have any other true concurrency mechanisms other than native threading, and they're too heavyweight for this purpose alone. On top of this they're useless for Python-only parallelism.
Huh? Core python has other concurrency mechanisms other than native threading. I don't know what your purpose is, but for mine (building horizontally scaleable systems of various types), they work fine. They're much easier to design with and maintain than using threads as well. They also work well in Python-only systems. If you're using "true" to exclude anything but threading, then you're just playing word games. The reality is that most problems don't need threading. The only thing it buys you over the alternatives is easy shared memory. Very few problems actually require that.
Personally, I'd like to see a modern threading model in Python, especially if it's tools can be extended to work with other concurrency mechanisms. But that's a *long* way into the future. Too far. It needs to be now. The downward spiral is already beginning. Mobile phones are going multicore. My next desktop will probably have 8 cores or more. All the heavyweight languages are firing up thread/STM standardizations and implementations to make this stuff more performant and easier than it already is.
Yes, Python needs something like that. You can't have it without breaking backwards compatibility. It's not clear you can have it without serious performance hits in Python's primary use area, which is single-threaded scripts. Which means it's probably a Python 4K feature. There have been a number of discussions on python-ideas about this. I submitted a proto-pep that covers most of that to python-dev for further discussion and approval. I'd suggest you chase those things down.
That said, it's perfectly reasonable to suggest changes you think will improve the popularity of the language. But be prepared to show that they're actually good, as opposed to merely possibly popular. This doesn't apply to "enabling" features. Features that make it possible for popular stuff to happen. Concurrency isn't popular, but parallelism is. At least where the GIL is concerned, an good alternative concurrency mechanism doesn't exist. (The popular one is native threading).
No, the process needs to apply to *all* changes. Even changes to implementation details - like removing the GIL. If your implementation that removes the GIL causes a 50% slowdown in single-threaded python code, it ain't gonna happen. But until you actually propose a change, it won't matter. Nothing's going to happen until someone actually does something more than talk about it. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org