6 ms·

Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popu

by ivoras 11y ago

Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popular as Perl is today if: it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3. The developers have dug themselves into this mess with frivolous differences ("print" a function, wanting to remove the "%" string operator, etc.), instead of spending the years on more productive features, now is the chance to dig themselves out again. It's a beautiful language, too bad the development choices were a bit sketchy.

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.
ZenoArrow 11y ago
> "it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3." Guido could do that if he decided that Python 4 would be based on PyPy (AFAIK, many people thought Python 3 would be based on PyPy too). Compatibility isn't 100% but if it was the main platform I'm sure it'd improve even faster.
- pyvpx 11y ago
  pypy still has the GIL.
  - Spiritus 11y ago
    Hopefully not for long: http://doc.pypy.org/en/latest/stm.html http://doc.pypy.org/en/latest/stm.html
    - DasIch 11y ago
      STM isn't magic. Transactions can and will silently fail and you lose your parallelism. You need additional tools to identify and debug failed transactions and you'll need to learn how to structure your code to avoid failed transactions. This might turn out to be quite difficult for non-trivial Python applications. STM is exciting but I think it's important to keep in mind that it's an experiment that while promising might still fail in practice.
      - ZenoArrow 11y ago
        > "STM isn't magic." What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.
        jerf 11y ago
        But first it has to actually work. So far, based on that page, it has suffered the same fate as all the other attempts to remove the GIL; mostly functional, but slower. And the numbers cited on that page put it on the rather slow side for single-threaded code for a GIL removal, too, which is what has always prevented previous efforts from getting merged in. I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.
sametmax 11y ago
Python 3 is much more than changing the print() statement (which, actually, is a great thing). It's about unicode by default. It's about removing 100 of duplicates way to do things to have only one. It's about making debug much, much easier, while at the same time allowing you to write better code with less mistakes. It's about removing a lot of boilerplate. It's about introducing new syntaxes allowing things not possible in python 2. If you see only print, you are missing the point. But good news, there are many projects working to improve the perfs and/or bypass the GIL this year.
- plesner 11y ago
  > If you see only print, you are missing the point. The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.
  - JupiterMoon 11y ago
    I think you might want to look into the 2to3 script. It should handle the conversion of your print statements.

by ivoras 11y ago

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.

ZenoArrow 11y ago

> "it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3." Guido could do that if he decided that Python 4 would be based on PyPy (AFAIK, many people thought Python 3 would be based on PyPy too). Compatibility isn't 100% but if it was the main platform I'm sure it'd improve even faster.

pyvpx 11y ago
pypy still has the GIL.
- Spiritus 11y ago
  Hopefully not for long: http://doc.pypy.org/en/latest/stm.html http://doc.pypy.org/en/latest/stm.html
  - DasIch 11y ago
    STM isn't magic. Transactions can and will silently fail and you lose your parallelism. You need additional tools to identify and debug failed transactions and you'll need to learn how to structure your code to avoid failed transactions. This might turn out to be quite difficult for non-trivial Python applications. STM is exciting but I think it's important to keep in mind that it's an experiment that while promising might still fail in practice.
    - ZenoArrow 11y ago
      > "STM isn't magic." What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.
      - jerf 11y ago
        But first it has to actually work. So far, based on that page, it has suffered the same fate as all the other attempts to remove the GIL; mostly functional, but slower. And the numbers cited on that page put it on the rather slow side for single-threaded code for a GIL removal, too, which is what has always prevented previous efforts from getting merged in. I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.

sametmax 11y ago

Python 3 is much more than changing the print() statement (which, actually, is a great thing). It's about unicode by default. It's about removing 100 of duplicates way to do things to have only one. It's about making debug much, much easier, while at the same time allowing you to write better code with less mistakes. It's about removing a lot of boilerplate. It's about introducing new syntaxes allowing things not possible in python 2. If you see only print, you are missing the point. But good news, there are many projects working to improve the perfs and/or bypass the GIL this year.

plesner 11y ago
> If you see only print, you are missing the point. The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.
- JupiterMoon 11y ago
  I think you might want to look into the 2to3 script. It should handle the conversion of your print statements.