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

The first year of free-threaded Python

labs.quansight.org

Post reply on HN
Print view View original

171–180 of 302 posts

Re: The first year of free-threaded Python

#171

Post by ptx »

realreality wrote: post #28
dotancohen wrote: post #20

Earlier quoted context omitted.

My current concern is a CRUD interface that transcribes audio in the background. The transcription is triggered by user action. I need the "transcription" field disabled until the transcript is complete and stored in the database, then allow the user to edit the transcription in the UI. Of course, while the transcription is in action the rest of the UI (Qt via Pyside) should remain usable. And multiple transcription…

Use `concurrent.futures.ThreadPoolExecutor` to submit jobs, and `Future.add_done_callback` to flip the transcription field when the job completes.

Although keep in mind that the callback will be "called in a thread belonging to the process" (say the docs), presumably some thread that is not the UI thread. So the callback needs to post an event to the UI thread's event queue, where it can be picked up by the UI thread's event loop and only then perform the UI updates.

I don't know how that's done in Pyside, though. I couldn't find a clear example. You might have to use a QThread instead to handle it.

Re: The first year of free-threaded Python

#172

Post by dhruvrajvanshi »

kstrauser wrote: post #143
biorach wrote: post #138

Earlier quoted context omitted.

> I think it’s supremely risky to hitch your wagon to their tech or services OK, finally, yes, this is very true, for specific parts of their tech. But banging on about EEE just distracts from this, more important message. > Make it increasingly hard to use for FOSS development by starting to add barriers a little at a time. ....and now you've lost me again

Note I wasn’t the one who said EEE upstream. I was just replying to the thread. Hanlon’s razor is a thing, and I generally follow it. It’s just that I’ve seen Microsoft make so many “oops, our bad!” mistakes over the years that purely coincidentally gave them an edge up over their competition, that I tend to distrust such claims from them. I don’t feel that way about all corps. Oracle doesn’t make little mistakes tha…

> Oracle doesn’t make little mistakes that accidentally harm the competition while helping themselves. No, they’ll look you in the eye and explain that they’re mugging you while they take your wallet. It’s kind of refreshingly honest in its own way.

Fucking hell bud :D

Re: The first year of free-threaded Python

#173

Post by reliabilityguy »

tomrod wrote: post #101
ogrisel wrote: post #53

Earlier quoted context omitted.

You cannot share arbitrarily structured objects in the `ShareableList`, only atomic scalars and bytes / strings. If you want to share structured Python objects between instances, you have to pay the cost of `pickle.dump/pickle.dump` (CPU overhead for interprocess communication) + the memory cost of replicated objects in the processes.

I can fit a lot of json into bytes/strings though?

What’s the point? The whole idea is to share an object, and not to serialize them whether it’s json, pickle, or whatever.

Re: The first year of free-threaded Python

#174

Post by sylware »

ipsum2 wrote: post #136
sylware wrote: post #97

Got myself a shiny python 3.13.3 (ssl module still unable to compile with libressl) replacing a 3.12.2, feels clearly slower. What's wrong?

python 3.13 doesn't ship with free-threaded Python compiled AFAIK.

You mean it is not default anymore?

Re: The first year of free-threaded Python

#175

Post by dhruvrajvanshi »

HDThoreaun wrote: post #36
jillesvangurp wrote: post #23

Earlier quoted context omitted.

You are not the only one who is afraid of changes and a bit change resistant. I think the issue here is that the reasons for this fear are not very rational. And also the interest of the wider community is to deal with technical debt. And the GIL is pure technical debt. Defensible 30 years ago, a bit awkward 20 years ago, and downright annoying and embarrassing now that world + dog does all their AI data processing w…

> But a simple solution to address your fears: simply don't use threads. You'll be fine. Im not worried about new code. Im worried about stuff written 15 years ago by a monkey who had no idea how threads work and just read something on stack overflow that said to use threading. This code will likely break when run post-GIL. I suspect there is actually quite a bit of it.

> Im not worried about new code. Im worried about stuff written 15 years ago by a monkey who had no idea how threads work and just read something on stack overflow that said to use threading. This code will likely break when run post-GIL. I suspect there is actually quite a bit of it.

I was with OP's point but then you lost me. You'll always have to deal with that coworker's shitty code, GIL or not.

Could they make a worse mess with multi threading? Sure. Is their single threaded code as bad anyway because at the end of the day, you can't even begin understand it? Absolutely.

But yeah I think python people don't know what they're asking for. They think GIL less python is gonna give everyone free puppies.

Re: The first year of free-threaded Python

#176

Post by igouy »

bayindirh wrote: post #137
igouy wrote: post #129

Earlier quoted context omitted.

You said it's the context that rots.

It's a matter of perspective, I guess... When you look from the program's perspective, the context changes and becomes unrecognizable, IOW, it rots. When you look from the context's perspective, the program changes by not evolving and keeping up with the context, IOW, it rots. Maybe we anthropomorphize both and say "they grow apart". :)

We say the context has breaking changes.

We say the context is not backwards compatible.

Re: The first year of free-threaded Python

#177

Post by notpushkin »

tomrod wrote: post #105
cjbgkagh wrote: post #102

Earlier quoted context omitted.

Perhaps flatbuffers would be better?

I love learning from folks on HN -- thanks! Will check it out.

Take a look at https://capnproto.org/ as well, while at it.

Neither solve the copying problem, though.

Re: The first year of free-threaded Python

#179

Post by igouy »

rocqua wrote: post #131
delusional wrote: post #71

Earlier quoted context omitted.

> Software rots No it does not. I hate that analogy so much because it leads to such bad behavior. Software is a digital artifact that can does not degrade. With the right attitude, you'd be able to execute the same binary on new machines for as long as you desired. That is not true of organic matter that actually rots. The only reason we need to change software is that we trade that off against something else. Instr…

Fair point, but there is an interesting question posed. Software doesn't rot, it remains constant. But the context around it changes, which means it loses usefulness slowly as time passes. What is the name for this? You could say 'software becomes anachronistic'. But is there a good verb for that? It certainly seems like something that a lot more than just software experiences. Plenty of real world things that have b…

obsolescence

Re: The first year of free-threaded Python

#180

Post by notpushkin »

ogrisel wrote: post #53
sgarland wrote: post #48

> Instead, many reach for multiprocessing, but spawning processes is expensive Agreed. > and communicating across processes often requires making expensive copies of data SharedMemory [0] exists. Never understood why this isn’t used more frequently. There’s even a ShareableList which does exactly what it sounds like, and is awesome. [0]: https://docs.python.org/3/library/multiprocessing.shared_mem...

You cannot share arbitrarily structured objects in the `ShareableList`, only atomic scalars and bytes / strings. If you want to share structured Python objects between instances, you have to pay the cost of `pickle.dump/pickle.dump` (CPU overhead for interprocess communication) + the memory cost of replicated objects in the processes.

We need a dataclass-like interface on top of a ShareableList.
Post reply on HN