Python 3.11 Performance Benchmarks Are Looking Fantastic

[schmidtbag]

While writing/understanding decorators might be hard for beginners, using them is usually easy…

Yes, and I'm sure walrus operators are easy to use too. But these are "features for the sake of features". They hardly add any value. You save a couple lines of code while making the overall language more complex. Good engineering eliminates all unnecessary functions, yet Python is adding them.

<rant>
Think of it like vehicle touchscreens that allow you to operate climate controls when there are also knobs/buttons for climate controls. Or in other vehicles, they offer a touchscreen and a separate input device to operate the screen without touching it. In other vehicles, they have menu options for stupid gimmicks like games or soothing sound effects. While some could argue "more options are better" and can help cater to varying preferences, all it does is add clutter and make the system harder for people to adapt to. It also means more chances of failure and greater difficulty of diagnosing problems.

I'm perfectly fine with new approaches to things, if they are replacements. I don't see an inherent issue with vehicles having touchscreens, because they helped replace the use of external devices and a slew of buttons. Python in and of itself was a very new take on software development, and I really like using Python; it was an easier-to-use replacement to Perl. But I'm really beginning to hate (in general) the trends we see today of everything just adding features that nobody asked for, just so they can claim more boxes are ticked than competitors. I'm tired of games that take 2+ hours to learn how to play, or have abilities that I only use once. I'd say it's a real problem when UIs are getting so complex that you need search functions just to run a calculator or change the speed of your mouse pointer. The scope of USB's capabilities have become so wide that it immensely complicates compatibility, and in turn, negates how "universal" it is meant to be. And don't get me started on the increasing dependencies and bloat of everyday programs.
I just want something that is both simple and efficient.
</rant>

[uid313]

Directly not, but through Termux yes.

Yeah, in some awkward arcane way you can run some script through some third-party application. It is not really useful as a development language make apps for normal people.

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

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

Yeah, even the Python wiki lists a few ways https://wiki.python.org/moin/Android
I think OP meant that it isn't straightforward and it doesn't integrate easily, it's not part of the official SDK and all that.
To be fair, it may very well be a reason not to use Python (if you need to make an Android app, it's probably not the right tool if it's unsupported), but it's not really a valid criticism to Python itself. There's nothing they can do, they don't control the platform and the lack of support isn't an inherent problem of Python but a product decision of Android.

Android doesn't support .NET, yet you can still use create .NET applications in C# using the Xamarin app platform
and run it on both Android and iOS.

[Mahboi]

For me, Python's attempts at making code clearer since 3.0 is my main issue with it. When you have an optional alternative approach that has a specific use-case and does not yield any noteworthy performance improvements, it's just simply a bad idea. It makes the language harder to learn for noobs, it's another potential point of failure, it adds work for the developers of alternative interpreters, and it can throw a stick in the spokes of hobbyist developers who just want to get from point A to point B and can't figure out how because they're referring to a tutorial/example using something they never needed to use.

If something can save 3+ lines of code, then I'm more interested. But at that point, I'd rather just use a function.

One of Python's "selling points" is being easy. Gimmicks like walrus operators and decorators make things harder for everyone who doesn't make a living off writing in Python.

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

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.

Personally, if Python focuses almost squarely on performance and slowly walks out of growth and then existence, I think it would have had the best run of any language except C.

(and if the C++ Ents would one day understand that piling even more obscure features every 3 years is actually not a good thing, it'd be a true miracle)

[blackshard]

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

[ssokolow]

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

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?)

[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?

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

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

[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]

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.