Live data from Hacker News

Python 3.11 vs 3.10 performance

github.com

201–210 of 460 posts

Re: Python 3.11 vs 3.10 performance

#201
post #53

I’d be curious to see the speed up compared to python 2.4. To see how far it’s come since I first got started with it.

it means you are not following PEP8 if you get non descriptive errors, it means you haven't followed proper exception handling/management its not the fault of Python but the developer. go ahead and downvote me but you if you mentioned parent's comment in an interview, you would not receive a call back or at least I hope the interviewer is realizing the skill gap.

Ah yes, the "why make things easier when you could do things the hard way" argument.

Re: Python 3.11 vs 3.10 performance

#202
post #55

Earlier quoted context omitted.

When is that coming? Yes the error messages are confusing in a big list comprehension.

Big list comprehensions cause confusion in many ways. KISS is crucial with them.

I agree. The rule of thumb I follow is that if the list comp doesn't fit on one line, whatever I'm doing is probably too complicated for a list comp.

Re: Python 3.11 vs 3.10 performance

#203

These speedups are awesome, but of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Having read about some of the changes [1], it seems like the python core committers preferred clean over fast implementations and have deviated from this mantra with 3.11. Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different lang…

A few people tried to excuse the slow python, but as far as I know the story, excuses are not necessary. Truth is that python was not meant to be fast, its source code was not meant to be fast, and its design was not optimized with the idea of being fast. Python was meant as a scrypting language that was easy to learn and work with on all levels and the issue of its slowness became important when it outgrew its role…

> python was not meant to scale

So many successful projects/technologies started out that way. The Web, JavaScript, e-mail. DNS started out as a HOSTS.TXT file that people copied around. Linus Torvalds announced Linux as "just a hobby, won't be big and professional like gnu". Minecraft rendered huge worlds with unoptimized Java and fixed-function OpenGL.

Re: Python 3.11 vs 3.10 performance

#204

These speedups are awesome, but of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Having read about some of the changes [1], it seems like the python core committers preferred clean over fast implementations and have deviated from this mantra with 3.11. Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different lang…

Perhaps they took a lesson from Perl; its code base was so complex as to be near unmaintainable.

In addition to the other point here about speed not being a target in the first place.

Re: Python 3.11 vs 3.10 performance

#205
post #191
post #139

Earlier quoted context omitted.

If I remember correctly iron python ran on mono it just didn't have all of the .net bits. I remember at the python conference when it was introduced he actually showed how you could bring up clippy or a wizard programmatically from python talking directly to the operating system through its native apis. Really the value came from the thread safe container/collections data types which are the foundation of high perfor…

Too bad .net is designed for windows and on linux the APIs feel like windows API that kinda sorta work on linux.

I've used a few .net applications on Linux and they work pretty well. But I've never actually tried to develop using mono. I really wish Microsoft had got all in on linux .net support 1 years ago

Re: Python 3.11 vs 3.10 performance

#206
post #200

Earlier quoted context omitted.

> Things should be fast by default. In over 90% of my work in the SW industry, being fast(er) was of no benefit to anyone. So no, it should not be fast by default.

Ha! Good luck convincing end-users that that's true.

I don't need to. Less than 10% of end users have put in requests for performance improvements.

Re: Python 3.11 vs 3.10 performance

#207

Cool improvement but changes very little when Python is x100 times slower than other GC languages.

This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)

JS is interpreted, and it's much much faster than Python.

Re: Python 3.11 vs 3.10 performance

#208
There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care.

So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations.

I hope this release was is not we got the optimizations but ignored the GIL part.

If anyone more knowledgable can review this and give some feedback I think will be here in HN

Re: Python 3.11 vs 3.10 performance

#209
post #55

Earlier quoted context omitted.

When is that coming? Yes the error messages are confusing in a big list comprehension.

Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.

Not even with nesting— as soon as it's long enough that I'm breaking it into multiple lines, I'm immediately like, okay this is long enough to just be a normal for-loop, or maybe a generator function. But it doesn't need to be a list comprehension any more.
Post reply on HN