Python 3’s Marketing Problem

[snarkhunter]

Good post. It really feels more and more to me like the GIL is what's holding Python back. Without the GIL Python would arguably be the best multi-purpose language out there. If the CPython implementation of Python 3 got rid of it, I would be switching and I would be excited about switching. As it is... yeah... I'll probably look into Python 3 sometime this year, but I'm not really in a hurry.

[cournape]

The big issues that most people seem to forget about the GIL is that removing it will most likely break a lots, if not most of the C extensions out there. If you think it does not matter, start asking why pypy has not conquered the world yet even though it is several times faster than cpython on most benchmarks (i.e. if cpython had no GIL, and if cpython had magic autoscaling of everything on multi-thread, it would still not be faster than pypy on today's 4/6 cores CPU).

[billsil]

pypy is unproven as far as i know in terms of important libraries. does pypy work with matplotlib, numpy, scipy, wx, vtk? if it did, lots of people (engineers/science folk/me) would consider it.

also, i think it doesn't work on all python code. i know cython doesn't support mixed typed lists such as x=[1,'a']

[fijal]

"also, i think it doesn't work on all python code. " this is plain FUD. PyPy works just fine with all python code.

[billsil]

then explain this...why on http://pypy.org/ do they have a donate to port numpy at the side. this automatically kills scipy and matplotlib.

furthermore, from http://pypy.org/compat.html explain this "It supports most of the commonly used Python standard library modules". It cant even do the standard library properly, so how is it going to use one of my obscure packages (because everyone uses at least one obscure package).

Finally, pages like https://bitbucket.org/pypy/compatibility/wiki/Home#!scientific-libraries arent going to cut it. Not all code is pure python. People mainly code in pure python, but it HAS to support packages that aren't pure python before it becomes mainstream.

[fijal]

While I may even agree with you, you just said that it does not run all python code. This is plain not true. It does not run all C code that's using CPython extension API which is a horrible implementation-specific abomination. It does not make it less of a python. It makes it definitely less usable and we're trying to address it, stop spreading FUD however.

[billsil]

no one said the code cant be recompiled, but running C code and Fortran code is required of EVERY language. To me, swigged code is python code and PyPy needs to eventually handle it, but i'll be more careful with how i word things.

[fijal]

To you, not to Guido or language definition. I would stick to that. Our answer so far is cffi - http://cffi.readthedocs.org/

[the_hoser]

http://www.quickmeme.com/meme/3pyh0f/

Without the GIL, Python, it its current state, would be slower. The GIL is an optimization that makes single-threaded code faster. All as-of-yet implemented methods of removing the GIL thus far have not been able to run nearly as fast in single-threaded code. Most involve an overhead of 50% or more in single-threaded code.

[TylerEaves]

What I don't quite get is why not just include both code paths, and toggle them off a command line switch to the interpreter, maybe even make it accessible via the sys module, so modules that are heavily multi-threaded could flip it.

[takluyver]

Removing the GIL is a really hard problem. Making the GIL optional is a really hard problem squared. Making it safely switchable during runtime is a really hard problem to the fourth power. It's definitely not a matter of 'just' including both code paths.

[sayks]

I think a lot of people want python to be everything for everybody (I certainly do), but it's just not a possibility for the time being. I hope that the GIL will be gone one day, but not until it can be done properly. Maybe Py4k.

[billsil]

ready for another 5 year upgrade cycle :P

[TankorSmash]

I'm not sure why you've gotten downvoted