Hacker News Reader

Comment by aklein | Hacker News Reader

"I want to point out one more time that the language doesn't require the GIL -- it's only the CPython virtual machine that has historically been unable to shed it."

http://www.artima.com/weblogs/viewpost.jsp?thread=214235

View on HN

I don't want to get into a software hipster flamewar about the definition of 'mainstream', but CPython is the Standard Python. When I click on "Windows Installer" on python.org, I get CPython.

Agreed, for now, CPython == Python. But PyPy aims to change this.

http://morepypy.blogspot.com/2011/06/global-interpreter-lock...

As long as they are able to run the same software, who cares?

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/

Well... Then they care. But I don't think the majority of Python code out there falls in these categories.

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.

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.

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.

Reply on news.ycombinator.com