6 ms·

Comments like this are so misguided and yet so common on HN. Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load

by orf 11y ago

Comments like this are so misguided and yet so common on HN. Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. Python 4 will just be the next release after Python 3.9.

ivoras 11y ago
It may very well never happen, that's a completely possible outcome. We'll see what it does to Python's popularity.
bhaak 11y ago
> Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. > > Python 4 will just be the next release after Python 3.9. Really? Why even change the major version then, when there are no breaking changes? Given that many Python programmers seem to be traumatized by the last major version switch, why even bother? Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?
- orf 11y ago
  > Really? Why even change the major version then, when there are no breaking changes? Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.
  - dragonwriter 11y ago
    > If Linus can bump the kernel to 4.0 because he felt like it so can Python. "Can" is not "should": I mean, Python can go from 3.x to Python 2020, go with year numbers for a while, then have Python XP, then go Python 7, Python 8, Python 8.1, and then skip to Python 10. But there's no good reason to do that.
dagw 11y ago
Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. The problem isn't just breaking compatibility, it's performance. There have been a number of experiments with removing the GIL going back (I think) to python 1.4. However every attempt has led to significant performance degradation in some part of the language.
plesner 11y ago
> Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. That's a bold statement. Can you elaborate on what those reasons are?
- orf 11y ago
  It's not a bold statement, it's one made time and time again by the cPython developers. In short: 1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic. 2. cPython is the reference implementation. It's source should be as simple as possible. 3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry and finally, 4. If you want/need a JIT then use PyPy, in all it's glory with all its upsides and downsides. PyPy is a big project with a lot of very very very smart people working on it. They've done an excellent job at JITting Python (and creating an impressive interpreter framework) but even they couldn't make a JIT that is anywhere near suitable for inclusion in cPython. A bunch of cPython hackers on python-dev have no chance. tldr: Want a JIT? Use PyPy.
  - plesner 11y ago
    By "bold" I'm also referring to your use of the words "freaking" and "ridiculous". 1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS. 2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation. 3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue. 4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make. I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.

by orf 11y ago

ivoras 11y ago

It may very well never happen, that's a completely possible outcome. We'll see what it does to Python's popularity.

bhaak 11y ago

> Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. > > Python 4 will just be the next release after Python 3.9. Really? Why even change the major version then, when there are no breaking changes? Given that many Python programmers seem to be traumatized by the last major version switch, why even bother? Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?

orf 11y ago
> Really? Why even change the major version then, when there are no breaking changes? Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.
- dragonwriter 11y ago
  > If Linus can bump the kernel to 4.0 because he felt like it so can Python. "Can" is not "should": I mean, Python can go from 3.x to Python 2020, go with year numbers for a while, then have Python XP, then go Python 7, Python 8, Python 8.1, and then skip to Python 10. But there's no good reason to do that.

dagw 11y ago

Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. The problem isn't just breaking compatibility, it's performance. There have been a number of experiments with removing the GIL going back (I think) to python 1.4. However every attempt has led to significant performance degradation in some part of the language.

plesner 11y ago

> Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. That's a bold statement. Can you elaborate on what those reasons are?

orf 11y ago
It's not a bold statement, it's one made time and time again by the cPython developers. In short: 1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic. 2. cPython is the reference implementation. It's source should be as simple as possible. 3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry and finally, 4. If you want/need a JIT then use PyPy, in all it's glory with all its upsides and downsides. PyPy is a big project with a lot of very very very smart people working on it. They've done an excellent job at JITting Python (and creating an impressive interpreter framework) but even they couldn't make a JIT that is anywhere near suitable for inclusion in cPython. A bunch of cPython hackers on python-dev have no chance. tldr: Want a JIT? Use PyPy.
- plesner 11y ago
  By "bold" I'm also referring to your use of the words "freaking" and "ridiculous". 1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS. 2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation. 3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue. 4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make. I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.