5 ms·

Presentation from Guido van Rossum at the Python Language Summit: https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf https://github.com/fas

Presentation from Guido van Rossum at the Python Language Summit: https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...

antman 5y ago
Comments on the points being made based on my experience - without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed) - No large PRs (how a 5x speedup can take place with small patches that no one figured out yet?) - a small team (not enough money, less risky if they tried to adopt other pypy-esque projects that are more advanced speed wise, a more comprehensive plan that would invite donations, I would certainly give. For this presentation I don't know)
- uluyol 5y ago
  WRT large PRs, it doesn't sound like they expect all the improvements to be from small changes. I think the point is the code will be changed in increments so that even large changes (overall) will be easier to review and offer feedback.
- kzrdude 5y ago
  I don't think "without breaking anyone's code" even needs to be a goal. Python has rolling deprecations and feature removals planned in the 3.x release series, and careful such feature transitions could be used to help JIT features or similar, too. To back up that fact: Python 3.10 will remove long-deprecated features, see issue tracker: https://bugs.python.org/issue41165 https://bugs.python.org/issue41165 and What's new, the Removed section: https://docs.python.org/3.10/whatsnew/3.10.html#removed https://docs.python.org/3.10/whatsnew/3.10.html#removed
- yjftsjthsd-h 5y ago
  > without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed) The Python 3 debacle is a beautifully worked example of why being backwards compatible is so important, and I can 100% sympathize with them not wanting to go through that again.
axaxs 5y ago
Well, glad he's coming around. Years back he seemed to stand by the notion that Python wasn't slow, showing a toy example. I remember thinking it was just condescending, whether intentional or not.
- takeda 5y ago
  I think years ago things were much different, also even today that might still be true. Among interpreted languages python is/was one of the faster ones. NodeJS has similar speed, and in some cases is faster. I don't know any other interpreted language though. People are also complaining about GIL, but ironically NodeJS is single threaded.
  - qsort 5y ago
    Nodejs is much faster than Python even for workloads where there's overlap in use-cases, like webapis and scripting. The only production language with performance in the ballpark of Python is Ruby. I agree that more often than not it simply isn't an issue, but CPython performance isn't much far ahead of toy languages, for a whole lot of reasons that we are all sick and tired of hearing.

antman 5y ago

Comments on the points being made based on my experience - without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed) - No large PRs (how a 5x speedup can take place with small patches that no one figured out yet?) - a small team (not enough money, less risky if they tried to adopt other pypy-esque projects that are more advanced speed wise, a more comprehensive plan that would invite donations, I would certainly give. For this presentation I don't know)

uluyol 5y ago
WRT large PRs, it doesn't sound like they expect all the improvements to be from small changes. I think the point is the code will be changed in increments so that even large changes (overall) will be easier to review and offer feedback.
kzrdude 5y ago
I don't think "without breaking anyone's code" even needs to be a goal. Python has rolling deprecations and feature removals planned in the 3.x release series, and careful such feature transitions could be used to help JIT features or similar, too. To back up that fact: Python 3.10 will remove long-deprecated features, see issue tracker: https://bugs.python.org/issue41165 https://bugs.python.org/issue41165 and What's new, the Removed section: https://docs.python.org/3.10/whatsnew/3.10.html#removed https://docs.python.org/3.10/whatsnew/3.10.html#removed
yjftsjthsd-h 5y ago
> without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed) The Python 3 debacle is a beautifully worked example of why being backwards compatible is so important, and I can 100% sympathize with them not wanting to go through that again.

axaxs 5y ago

Well, glad he's coming around. Years back he seemed to stand by the notion that Python wasn't slow, showing a toy example. I remember thinking it was just condescending, whether intentional or not.

takeda 5y ago
I think years ago things were much different, also even today that might still be true. Among interpreted languages python is/was one of the faster ones. NodeJS has similar speed, and in some cases is faster. I don't know any other interpreted language though. People are also complaining about GIL, but ironically NodeJS is single threaded.
- qsort 5y ago
  Nodejs is much faster than Python even for workloads where there's overlap in use-cases, like webapis and scripting. The only production language with performance in the ballpark of Python is Ruby. I agree that more often than not it simply isn't an issue, but CPython performance isn't much far ahead of toy languages, for a whole lot of reasons that we are all sick and tired of hearing.