Hacker News Reader

Comment by patrick91 | Hacker News Reader

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

View on HN

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)

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.

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 and What's new, the Removed section: https://docs.python.org/3.10/whatsnew/3.10.html#removed

> 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.

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.

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.

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.

Reply on news.ycombinator.com