Chris Angelico wrote: > On Mon, Feb 23, 2015 at 6:41 PM, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: >>>> - and you must be using libraries and tools which prevent you moving to >>>> Jython or IronPython or some other alternative. >>> >>> I don't get this at all. Why should I not want Python to have the same >>> capabilities? >> >> Python does have the same capabilities. Jython and IronPython aren't >> different languages, they are Python. > > Presuming that he meant CPython, one other good reason for wanting to > stick with it rather than jump to another interpreter is all the new > features of the recent versions. (Do Jython or IronPython support > Python 3.x at all, even?) Every new release of CPython has new and > cool features, and the other Pythons are generally playing catch-up.
Most people are not using the bleeding edge version of Python, and even those who do, aren't usually using it in production. There are still plenty of people using Python 2.3 in production, and even a few using 1.5. But as you say, there are good reasons for wishing to stick to CPython over Jython, IronPython, PyPy or Stackless, let alone less mature or experimental implementations. I get that. But the point I am trying to make is that there are an awful lot of people who mindlessly bash "Python" the language for "the GIL". The argument is even worse than "Python sux cos significant whitespace", because the whitespace issue at least is mostly a matter for personal preference, but the GIL appears to be a technical, objective judgement. Trouble is that it is *wrong*. Python the language doesn't have a GIL. Implementations with a GIL aren't slower because of it, they are faster. And removing the GIL doesn't necessarily speed up multithreaded code. So they are technically wrong, and in practical terms often wrong too. I am *happy* when people come up with nuanced and considered opinions that they found that Python was unsuitable for some specific project, and can give good cogent reasons for it. If they can demonstrate reasons for believing that CPython would have been suitable *if the GIL was removed*, that's great. Given sufficiently many such projects, and 1- and 2-core CPUs gradually becoming obsolete, the time may come for somebody else to take a shot at removing the GIL from CPython again. That time might even be now, if there is a volunteer. And C coders out there want a nice meaty project to work on during rainy weekends? -- Steve -- https://mail.python.org/mailman/listinfo/python-list
