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

61–70 of 302 posts

Re: The first year of free-threaded Python

#61

Post by porridgeraisin »

bratao wrote: post #55
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

This is a common mistake and very badly communicated. The GIL do not make the Python code thread-safe. It only protect the internal CPython state. Multi-threaded Python code is not thread-safe today.

Internal cpython state also includes say, a dictionary's internal state. So for practical purposes it is safe. Of course, TOCTOU, stale reads and various race conditions are not (and can never be) protected by the GIL.

Re: The first year of free-threaded Python

#62

Post by falcor84 »

pjmlp wrote: post #50
falcor84 wrote: post #44

Earlier quoted context omitted.

It wouldn't have bothered me if you just said "Facebook" - I probably wouldn't have even noticed it. But I'm really curious why you chose to write "Facebook", then apparently noticed the issue, and instead of replacing it with "Meta" decided to add the much longer "(no need to correct me on the name)". What axe are you grinding?

Yes, because I am quite certain someone without anything better to do would correct me on that. For me Facebook will always be Facebook, and Twitter will always be Twitter.

> Yes, because I am quite certain someone without anything better to do would correct me on that.

Well, you sure managed to avoid that by setting up camp on that hill. Kudos on so much time saved.

> For me Facebook will always be Facebook, and Twitter will always be Twitter.

Well, for me the product will always be "Thefacebook", but that's since I haven't used it since. But I do respect that there's a company running it now that does more stuff and contributes to open source projects.

Re: The first year of free-threaded Python

#63

Post by qznc »

AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

Worst case is probably that it is like a "Python4": Things break when people try to update to non-GIL, so they rather stay with the old version for decades.

Re: The first year of free-threaded Python

#64

Post by breadwinner »

txdv wrote: post #5
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

how does the the language being dynamic negatively affect the complexity of multithreading?

When the language is dynamic there is less rigor. Statically checked code is more likely to be correct. When you add threads to "fast and loose" code things get really bad.

Re: The first year of free-threaded Python

#65

Post by YouWhy »

Hey, I've been developing professionally with Python for 20 years, so wanted to weigh in:

Decent threading is awesome news, but it only affects a small minority of use cases. Threads are only strictly necessary when it's prohibitive to message pass. The Python ecosystem these days includes a playbook solution for literally any such case. Considering the multiple major pitfalls of threads (i.e., locking), they are likely to become a thing useful only in specific libraries/domains and not as a general.

Additionally, with all my love to vanilla Python, anyone who needs to squeeze the juice out of their CPU (which is actually memory bandwidth) has a plenty of other tools -- off the shelf libraries written in native code. (Honorable mention to Pypy, numba and such).

Finally, the one dramatic performance innovation in Python has been async programming - I warmly encourage everyone not familiar with it to consider taking a look.

Re: The first year of free-threaded Python

#66

Post by wisty »

biorach wrote: post #60
bgwalter wrote: post #47

Earlier quoted context omitted.

They were quite a bit behind the schedule that was promised five years ago. Additionally, at this stage the severe political and governance problems cannot have escaped Microsoft. I imagine that no competent Microsoft employee wants to give his expertise to CPython, only later to suffer group defamation from a couple of elected mediocre people. CPython is an organization that overpromises, allocates jobs to the obedi…

> CPython is an organization that overpromises, allocates jobs to the obedient and faithful while weeding out competent dissenters. This stinks of BS

It sounds like an oblique reference to that time they temporarily suspended one of the of the most valuable members of the community, apparently for having the audacity to suggest that their powers to suspend members of the community seemed a little arbitrary and open to abuse.

Re: The first year of free-threaded Python

#67

Post by biorach »

wisty wrote: post #66
biorach wrote: post #60

Earlier quoted context omitted.

> CPython is an organization that overpromises, allocates jobs to the obedient and faithful while weeding out competent dissenters. This stinks of BS

It sounds like an oblique reference to that time they temporarily suspended one of the of the most valuable members of the community, apparently for having the audacity to suggest that their powers to suspend members of the community seemed a little arbitrary and open to abuse.

Well they could just say that instead of wasting people's time with oblique references

Re: The first year of free-threaded Python

#68

Post by biorach »

falcor84 wrote: post #62
pjmlp wrote: post #50

Earlier quoted context omitted.

Yes, because I am quite certain someone without anything better to do would correct me on that. For me Facebook will always be Facebook, and Twitter will always be Twitter.

> Yes, because I am quite certain someone without anything better to do would correct me on that. Well, you sure managed to avoid that by setting up camp on that hill. Kudos on so much time saved. > For me Facebook will always be Facebook, and Twitter will always be Twitter. Well, for me the product will always be "Thefacebook", but that's since I haven't used it since. But I do respect that there's a company running…

> Well, you sure managed to avoid that by setting up camp on that hill. Kudos on so much time saved.

Why are you picking a fight about this?

Re: The first year of free-threaded Python

#69

Post by fulafel »

miohtama wrote: post #6
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

GIL or no-GIL concerns only people who want to run multicore workloads. If you are not already spending time threading or multiprocessing your code there is practically no change. Most race condition issues which you need to think are there regardless of GIL.

A lot of Python usage is leveraging libraries with parallel kernels inside written in other languages. A subset of those is bottlenecked on Python side speed. A sub-subset of those are people who want to try no-GIL to address the bottleneck. But if non-GIL becomes pervasive, it could mean Python becomes less safe for the "just parallel kernels" users.

Re: The first year of free-threaded Python

#70

Post by rednafi »

heybrendan wrote: post #30

I am a Python user, but far from an expert. Occasionally, I've used 'concurrent.futures' to kick off running some very simple functions, at the same time. How are 'concurrent.futures' users impacted? What will I need to change moving forward?

It’s going to get faster since threads won’t be locked on GIL. If you’re locking shared objects correctly or not using them all, then you should be good.
Post reply on HN