Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.11 vs 3.10 performance

github.com

Post reply on HN
Print view View original

311–320 of 460 posts

Re: Python 3.11 vs 3.10 performance

#311

Post by e-master »

dec0dedab0de wrote: post #224
alexfromapex wrote: post #36

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.

This is the first time I ever heard someone complain about Python's error messages in the 10+ years I've been using it. Even people who just learned it, pick up reading tracebacks after about a day of practice. The only problem I ever see is if a library swallows too much, and gives a generic error, but that's not something the language can fix. I really hope they don't change things too much.

I only rarely delve into the python world, but as a .net developer I always found it odd and confusing that the error message comes after the stack trace in python. I don’t see people complaining about it, so maybe it’s just a matter of habit?

Re: Python 3.11 vs 3.10 performance

#312

Post by lmm »

maxbond wrote: post #109
amelius wrote: post #96

Earlier quoted context omitted.

"Premature optimization is the root of all evil." -- Donald Knuth

This certainly does not mean, "tolerate absurd levels of technical debt, and only ever think about performance in retrospect."

> tolerate absurd levels of technical debt

In my experience it's far more common for "optimizations" to be technical debt than the absence of them.

> only ever think about performance in retrospect

From the extra context it pretty much does mean that. "but only after that code has been identified" - 99.999% of programmers who think they can identify performance bottlenecks other than in retrospect are wrong, IME.

Re: Python 3.11 vs 3.10 performance

#313

Post by metadat »

mgaunard wrote: post #302
metadat wrote: post #299

Earlier quoted context omitted.

Being friendly is inclusive and generally a winning strategy compared to others. The underlying source of the Politics of Python and associated perceptions stems from the core team's culture of not being "friendly".

People act according to their interests. They have no obligation to go out of their way to cater to yours. The entitlement of the new generation of open-source contributors to require political correctness or friendliness is so destructive it's ridiculous. I wouldn't want to be involved with any project that prioritizes such zealotry on top of practicality.

It's not about entitlement so much as about ensuring the project can reach it's full potential and continue to stay relevant and useful in perpetuity as people come and go.

The world constantly changes, projects adapt or become less useful.

Re: Python 3.11 vs 3.10 performance

#314

Post by fragmede »

prionassembly wrote: post #254
ketralnis wrote: post #110

Earlier quoted context omitted.

> you can either dig into a foreign codebase ... > Or you could rewrite your application Programmers love to save an hour in the library by spending a week in the lab

Everyone likes to shirk away from their jobs; engineers and programmers have ways of making their fun (I'm teaching myself how to write parsers by giving each project a DSL) look like work. Lingerie designers or eyebrow barbers have nothing of the sort, they just blow off work on TikTok or something.

TikTok’s got some fun coding content, if you can get the algorithm to surface it to you.

Re: Python 3.11 vs 3.10 performance

#315

Post by estebank »

dralley wrote: post #303
CobrastanJorji wrote: post #228

Earlier quoted context omitted.

I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.

The exception is std::io::Error, which doesn't provide any information about which file failed to be opened/closed/read/whatever. I know this is because doing so would require an allocation, but it's still painful.

The GP comment is referring to the compile time diagnostics and not the runtime diagnostics, which certainly could do with some out-of-the-box improvements but that you can extend in your own code (as opposed to compile errors which crate authors have little control over, at least for now).

Re: Python 3.11 vs 3.10 performance

#316

Post by rowanG077 »

dralley wrote: post #303
CobrastanJorji wrote: post #228

Earlier quoted context omitted.

I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.

The exception is std::io::Error, which doesn't provide any information about which file failed to be opened/closed/read/whatever. I know this is because doing so would require an allocation, but it's still painful.

huh a stack trace should tell you that.

Re: Python 3.11 vs 3.10 performance

#317

Post by lmm »

ChuckNorris89 wrote: post #57
int_19h wrote: post #27

Earlier quoted context omitted.

> one wonders why they haven't been a low-hanging fruit over the past 25 years. From the very page you've linked to: "Faster CPython explores optimizations for CPython. The main team is funded by Microsoft to work on this full-time. Pablo Galindo Salgado is also funded by Bloomberg LP to work on the project part-time."

Hmm, looks like corporate money gets sh*t done.

Yep. That's the thing about the open source dream; especially for work like this that requires enough time commitment to understand the whole system, and a lot of uninteresting grinding details such that very few people would do it for fun, you really need people being funded to work on it full-time (and a 1-year academic grant probably doesn't cut it), and businesses are really the only source for that.

Re: Python 3.11 vs 3.10 performance

#318

Post by tialaramex »

dralley wrote: post #303
CobrastanJorji wrote: post #228

Earlier quoted context omitted.

I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.

The exception is std::io::Error, which doesn't provide any information about which file failed to be opened/closed/read/whatever. I know this is because doing so would require an allocation, but it's still painful.

Your parent is thinking about the compiler errors, whereas std::io::Error (which I'm guessing you mean) is an Error type your software can get from calling I/O functions at runtime.

To be fair, if decorating the error with information about a filename is what you needed, since Rust's Error types are just types nothing stops you making your function's Error type be the tuple (std::io::Error, &str) if you have a string reference, or (though this seems terribly inappropriate in production code) leaking a Box to make a static reference from a string whose lifetime isn't sufficient.

Re: Python 3.11 vs 3.10 performance

#319

Post by liuliu »

lmm wrote: post #304
metadat wrote: post #295

Earlier quoted context omitted.

In Golang you can spawn a green thread on any function call with a single keyword: `go'. The ergonomics are such that it's not difficult to use. Why can't or shouldn't we have a mechanism comparably fantastic and easy to use in Python?

Because making it easy to write C/C++ extensions that work the way you expect (including for things like passing a Python callback to a C/C++ library) has always been a priority for Python in a way that it isn't for Golang?

Any C/C++ extensions that wants to enable more efficient Python has to learn GIL and how to manipulate that as well. Including not limited to: how to give up GIL (so that other Python code can progress); how to prepare your newly initiated threads to be Python GIL friendly etc.

Personally, GIL is more surprising to me when interop with Python.

Re: Python 3.11 vs 3.10 performance

#320

Post by TillE »

simias wrote: post #52
uniqueuid wrote: post #2

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…

I suspect that the amount of people and especially companies willing to spend time and money optimizing Python are fairly low. Think about it: if you have some Python application that's having performance issues you can either dig into a foreign codebase to see if you can find something to optimize (with no guarantee of result) and if you do get something done you'll have to get the patch upstream. And all that "only…

> Or you could rewrite your application in part or in full in Go, Rust, C++

Or you can just throw more hardware at it, or use existing native libraries like NumPy. I don't think there are a ton of real-world use cases where Python's mediocre performance is a genuine deal-breaker.

If Python is even on the table, it's probably good enough.

Post reply on HN