Steve Holden wrote: > Quite right too. You haven't even sacrificed a chicken yet ...
Hopefully we don't get to that point. > You write as though the GIL was invented to get in the programmer's way, > which is quite wrong. It's there to avoid deep problems with thread > interaction. Languages that haven't bitten that bullet can bite you in > quite nasty ways when you write threaded applications. I know it was put there because it is meant to be a good thing. However, it gets in my way. I would be perfectly happy if it were gone. I've never written code that assumes there's a GIL. I always write my code with all shared writable objects protected by locks. It's far more portable, and a good habit to get into. You realize that because of the GIL, they were discussing (and may have already implemented) Java style synchronized dictionaries and lists for IronPython simply because python programmers just assume they are thread safe thanks to the GIL. I always hated that about Java. If you want to give me thread safe collections, fine, they'll be nice for sharing between threads, but don't make me use synchronized collections for single-threaded code. You'll notice the newer Java collections are not synchronized, it would seem I'm not alone in that opinion. > Contrary to your apparent opinion, the GIL has nothing to do with > reference-counting. Actually it does. Without the GIL reference counting is not thread safe. You have to synchronize all reference count accesses, increments, and decrements because you have no way of knowing which objects get shared across threads. I think with Python's current memory management, the GIL is the lesser evil. I'm mostly writing this to provide a different point of view, many people seem to think (previously linked blog) that there is no downside to the GIL, and that's just not true. However, I don't expect that the GIL can be safely removed from CPython. I also think that it doesn't matter because projects like IronPython and PyPy are very likely the way of the future for Python anyway. Once you move away from C there are so many more things you can do. > I think the suggestion was rather that abandoning Python because of the > GIL might be premature optimisation. But since you appear to be sticking > with it, that might have been unnecessary advice. I would never abandon Python, and I hold the development team in very high esteem. That doesn't mean there's a few things (like the GIL, or super) that I don't like. But overall they've done an excellent job on the 99% of things the've got right. I guess we don't say that enough. I might switch from CPython sometime to another implementation, but it won't be because of the GIL. I'm very fond of the .net framework as a library, and I'd also rather write performance critical code in C# than C (who wouldn't?) I'm also watching PyPy with interest. -Sandra -- http://mail.python.org/mailman/listinfo/python-list
