News for hackers. Stuff that matters.
Re:Python GIL removal question by rbanffy on Friday August 12, 2011 @08:37PM (#2879833)
As long as they are able to run the same software, who cares?
Re:Python GIL removal question by davvid on Friday August 12, 2011 @10:01PM (#2879996)
Anyone who links against (or depends on software that links against) libpython*.so cares.

Here are two examples of products that ship python. You can't just "swap out the interpreter".

http://www.thefoundry.co.uk/products/nuke/ http://usa.autodesk.com/maya/

Re:Python GIL removal question by rbanffy on Saturday August 13, 2011 @12:17AM (#2880225)
Well... Then they care. But I don't think the majority of Python code out there falls in these categories.
Re:Python GIL removal question by rat on Sunday August 14, 2011 @07:07AM (#2883369)
python is widely used as a scripting language. If you are on windows they will probably ship with their own python. Even if not they will probably have to use something to glue the main program to the interpreter which will probably not be compatible with any python implementation.
Re:Python GIL removal question by pnathan on Friday August 12, 2011 @10:48PM (#2880084)
Well, if Python runs really fast for the clued-in users who use PyPy and pretty slow for the non-clueful, then I'm providing my users with a bad experience. I need to be able to reliably deliver fast code without futzing around with custom installs of Python just to deliver an app.
Re:Python GIL removal question by rbanffy on Sunday August 14, 2011 @08:33AM (#2883472)
Actually, it runs well enough in CPython unless you are doing something terrible with your code. What it doesn't do is execute more than one thread within the same process. If you don't need to share in-memory data between your threads (which is something you really should avoid, for your own sake), you can use the same mechanism you use to create a thread to create a new process.