News for hackers. Stuff that matters.
Re:Python 3.11 vs 3.10 performance by MrYellowP on Wednesday July 06, 2022 @11:26AM (#32002375)
I don't wonder. For me it seems pretty clear.

I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that.

When talking about low-hanging fruits, it's important to consider who they're for. The intended target audience. It's important to ask ones self who grabs for low-hanging fruits and why they need to be prioritized.

And with that in mind, I think the answer is actually obvious: Python never required the speed, because it's just so good.

The language is so popular, people search for and find ways around its limitations, which most likely actually even increases its popularity, because it gives people a lot of space to tinker in.

Re:Python 3.11 vs 3.10 performance by pdpi on Wednesday July 06, 2022 @11:37AM (#32002534)
> Low-hanging fruits attract people who can't reach higher than that.

Do we have completely different definitions of low-hanging fruit?

Python not "requiring" speed is a fair enough point if you want to argue against large complex performance-focused initiatives that consume too much of the team's time, but the whole point of calling something "low-hanging fruit" is precisely that they're easy wins — get the performance without a large effort commitment. Unless those easy wins hinder the language's core goals, there's no reason to portray it as good to actively avoid chasing those wins.

Re:Python 3.11 vs 3.10 performance by int_19h on Wednesday July 06, 2022 @11:43AM (#32002616)
It can also be a "low-hanging fruit" in a sense that it's possible to do without massive breakage of the ecosystem (incompatible native modules etc). That is, it's still about effort - but effort of the people using the end result.
Re:Python 3.11 vs 3.10 performance by MrYellowP on Wednesday July 06, 2022 @11:45AM (#32002644)
> is precisely that they're easy wins — get the performance without a large effort commitment.

Oh, that's not how I interpret low-hanging fruits. From my perspective a "low-hanging fruit" is like cheap pops in wrestling. Things you say of which you know that it will cause a positive reaction, like saying the name of the town you're in.

As far as I know, the low-hanging fruit isn't named like that because of the fruit, but because of those who reach for it.

My reason for this is the fact that the low-hanging fruit is "being used" specifically because there's lots of people who can reach it. The video gaming industry as a whole, but specifically the mobile space, pretty much serves as perfect evidence of that.

Edit:

It's done for a certain target audience, because it increases exposure and interest. In a way, one might even argue that the target audience itself is a low-hanging fruit, because the creators of the product didn't care much about quality and instead went for that which simply impresses.

I don't think python would have gotten anywhere if they had aimed for that kind of low-hanging fruit.

Re:Python 3.11 vs 3.10 performance by pdpi on Wednesday July 06, 2022 @12:37PM (#32003407)
Ah, ok. We're looking at the same thing from different perspectives then.

What I'm describing, which is the sense I've always seen that expression used as in engineering, and what GP was describing, is: this is an easy low-risk project that have a good chance of producing results.

E.g. If you tell me that your CRUD application suffers from slow reads, the low-hanging fruit is stuff like making sure your queries are hitting appropriate indices instead of doing full table scans, or checking that you're pooling connections instead of creating/dropping connections for every individual query. Those are easy problems to check for and act on that don't require you to try to grab the fruit hard-to-reach fruit at the top of the tree like completely redesigning or DB schema or moving to a new DB engine altogether.

Re:Python 3.11 vs 3.10 performance by kgwgk on Thursday July 07, 2022 @09:18AM (#32013695)
https://en.wiktionary.org/wiki/low-hanging_fruit

Easily obtained gains; what can be obtained by readily available means

https://www.merriam-webster.com/dictionary/low-hanging%20fru...

the obvious or easy things that can be most readily done or dealt with in achieving success or making progress toward an objective

"Maria and Victor have about three months' living expenses set aside. That's actually pretty good …. But I urged them to do better …. Looking at their monthly expenses, we found a few pieces of low-hanging fruit: Two hundred dollars a month on clothes? I don't think so. Another $155 for hair and manicures? Denied."

"As the writers and producers sat down in spring 2007 to draw the outlines of Season 7, they knew, Mr. Gordon said, that most of the low-hanging fruit in the action genre had already been picked."

"When business types talk about picking low-hanging fruit, they don't mean, heaven forbid, doing actual physical labor. They mean finding easy solutions."

https://dictionary.cambridge.org/dictionary/english/low-hang...

something that is easy to obtain, achieve, or take advantage of

"The easy changes have all been made. All the low-hanging fruit has been picked."

"When cutting costs, many companies start with the low-hanging fruit: their ad budgets."

"For the beauty-care industry, the teen demographic is a new category for them - low-hanging fruit."

"I'm a great believer in picking low-hanging fruit. Start with what's easy, and go higher later."

"This legislation is some of the low-hanging fruit - the issues that we can agree upon across parties and regions."

Re:Python 3.11 vs 3.10 performance by uniqueuid on Wednesday July 06, 2022 @11:28AM (#32002394)
I see your point, but it directly conflicts with the effort many people put into producing extremely fast libraries for specific purposes, such as web frameworks (benchmarked extensively), ORMs and things like json and date parsing, as seen in the excellent ciso8601 [1] for example.

[1] https://github.com/closeio/ciso8601

Re:Python 3.11 vs 3.10 performance by dagmx on Wednesday July 06, 2022 @11:36AM (#32002516)
I disagree that it conflicts. There's an (implied) ceiling on Python performance, even after optimizations. The fear has always been that removing the design choices that cause that ceiling, would result in a different, incompatible language or runtime.

If everyone knows it's never going to reach the performance needed for high performance work, and there's already an excellent escape hatch in the form of C extensions, then why would people be spending time on the middle ground of performance? It'll still be too slow to do the things required, so people will still be going out to C for them.

Personally though, I'm glad for any performance increases. Python runs in so much critical infrastructure, that even a few percent would likely be a considerable energy savings when spread out over all users. Of course that assumes people upgrade their versions...but the community tends to be slow to do so in my experience.

Re:Python 3.11 vs 3.10 performance by mywittyname on Wednesday July 06, 2022 @11:46AM (#32002669)
Isn't this the point made in the last paragraph, about how people find ways around the limitations?
Re:Python 3.11 vs 3.10 performance by avgcorrection on Wednesday July 06, 2022 @12:11PM (#32003018)
> I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that.

Ah! So they are so tall that picking the low-hanging fruit would be too inconvenient for them.

Talk about stretching an analogy too far.