Python 3.11 Performance Benchmarks Are Looking Fantastic

[Agno]

I'd like to see some RAM usage benchmark too. Historically RAM usage has been a big issue for python. For some work you can afford to wait an 20-40% more time, but if you run out of system memory you just need a better machine (or money to scale up your paid hosted system).

[sinepgib]

That's true, but, in this case, given that Java's annotations apparently came first, and finding "decorator pattern" when looking for an equivalent to that syntax makes things more difficult, I think it was a bad idea.

Yeah, it could make sense for the syntax part to have a different name. The implementation of a decorator in Python, tho, is the most literal application of the concept in terms of being a function taking a callable and returning another with added behavior.

[ssokolow]

To be fair, "decorator" is a more standard name for the feature, it comes from the old decorator pattern you would use in object oriented languages.

That's true, but, in this case, given that Java's annotations apparently came first, and finding "decorator pattern" when looking for an equivalent to that syntax makes things more difficult, I think it was a bad idea.

[uid313]

When you are going to deny what people see with their own eyes, you are just a religious fanatic who doesn’t believe in the truth…

So what is this supposed Android game that is written in Python?

[JanC]

The game I play the most on my Android phone is written in Python.

No, you don't, and not it isn't.

When you are going to deny what people see with their own eyes, you are just a religious fanatic who doesn’t believe in the truth…

[sinepgib]

How is this different, aside from making it difficult for Python users to google for the same feature in other languages because "decorator" means something else elsewhere?

To be fair, "decorator" is a more standard name for the feature, it comes from the old decorator pattern you would use in object oriented languages.

[schmidtbag]

But I believe that no matter what language it is, Time will get to it eventually. All languages age and reach the end of their "natural" growth and then only grow either in worse ways, or cut out things they used to do.

I don't think that's necessarily true, or doesn't have to be anyway. As you alluded to, C is ancient and remains popular because it does everything it needs to do and nothing more. It grew in ways that helped it adapt to modern hardware; it's growth was evolutionary, and necessary. The variants like C# or C++ were nice because they allowed the language to be expanded without meddling with the original functionality. Other languages can do the same and there's no reason why Python couldn't as well. Python doesn't really have a complete replacement. It's a quirky language and it does everything it's meant to do fairly well, albeit, slowly. The only thing it needs for growth is more documentation, better performance, and as blackshard pointed out, do something about GIL. It doesn't need anything else, but as more unnecessary features keep getting added, it diminishes the value of the language.

[sinepgib]

They've tried to get rid of it multiple times over the last two decades and every attempt has tanked single-threaded performance so badly as to make it an unacceptable change. (Do you really want to get a speed up out of 8 cores if you need 2 or 3 of them just to match the performance you were getting out of one before?)

The current attempt doesn't take as high a hit, and the author also included some single core optimizations that offset the loss and give a net positive. Granted, if you applied just those the single core speed would be greater than if you also apply the GIL removal, but the fact is you're still going from A to B where A is slower both in single and multi core code than B.

[sinepgib]

The GIL! When the CPython interpreter will get into the third millennium?

There's ongoing work, but it's not quite so easy to remove. The current implementation of reference counting relies too heavily on it. The proposed solution should be seamless in code written correctly, but:
1. It would break the ABI, every native extension would need recompiling, because The Right Way (TM) for managing the RCs is through macros;
2. Many extensions don't even use the macros and access the RC directly, so they'd need to adapt to the new way that uses two different counters (it's something like one for crossing thread boundaries and a local one or something like that).

This is why Van Rossum left, isn't it? Disagreements on how to make it grow and what was "Pythonic" and wasn't.

Not exactly because of that and not exactly left. He just stepped down as BDFL because the discussion was too heated and there was no way for him as an individual to satisfy everyone. The problem with dictatorships in software is that it's easier to fracture the whole community over a decision. But he didn't give up on the language because things didn't go his way.
Note he does still work on Python: he's actually the leader of the Microsoft team behind the "Faster CPython Project".

[ssokolow]

Gimmicks like […] decorators make things harder for everyone who doesn't make a living off writing in Python.

Java and C# have the same thing and call them annotations (Java even uses the same @-prefixed syntax), and Rust has "attribute macros", which look like a cross between C's preprocessor directives and C#'s annotation syntax.

How is this different, aside from making it difficult for Python users to google for the same feature in other languages because "decorator" means something else elsewhere?