On Sat, Feb 18, 2012, Jeremy McMillan wrote: > > The declarative programming style makes it trivial to graph which code > cares about which objects in memory. That forces the programmer to solve > the problems a priori, which as it turns out, are the real issue with > effectively getting rid of the GIL in Python, thus ending this debate. > > http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html > > What we need is smarter memory management, but I think it needs to be > somewhere between the Spartan approach of functional languages and the > relatively cushy GC'ed object-oriented languages.
As Dave's post and comments make clear, a lot of the problem with switching Python's memory management comes from interfacing with external libraries. As long as one of Python's primary goals is to make it easy to hook up external libraries, it will be difficult to get enough energy toward removing the GIL. -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "Do not taunt happy fun for loops. Do not change lists you are looping over." --Remco Gerlich _______________________________________________ concurrency-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/concurrency-sig
