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

Free-threaded CPython is ready to experiment with

labs.quansight.org

Post reply on HN
Print view View original

281–290 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#281

Post by Certhas »

bdd8f1df777b wrote: post #195
rty32 wrote: post #99

Earlier quoted context omitted.

I think it is beneficial to some people, but not a lot. My guess is that most Python users (from beginners to advanced users, including many professional data scientists) have never heard of GIL or thought of doing any parallelization in Python . Code that needs performance and would benefit from multithreading, usually written by professional software engineers, likely isn't written in Python in the first place. It…

> Code that needs performance and would benefit from multithreading, usually written by professional software engineers, likely isn't written in Python in the first place. There are a lot of simple cases where multi-threading can easily triple or quadruple the performance.

But multiprocessing can't?

I used to write a ton of MPI based parallel python. It's pretty straightforward. But one could easily imagine trying to improve the multiprocessing ergonomics rather than introducing threading. Obviously the people who made the choice to push forward with this are aware of these options, too. Still mildly puzzling to me why threads for Python are needed/reasonable.

Re: Free-threaded CPython is ready to experiment with

#282

Post by pletnes »

simonw wrote: post #126
arp242 wrote: post #80

Earlier quoted context omitted.

Managing a farm of virtualenvs and mucking about with my PATH doesn't address the user-installable problem at all. And it seems there's a new tool to try every few months that really will fix all problems this time. And maybe if you're a Python developer working on the code every day that's all brilliant. But most people aren't Python developers, and I just want to try that "Show HN" project or whatnot. Give me a sin…

"Give me a single command I can run. Always. For any project. And that always works." pipx install X

Pipx is great! Although, I always seem to have to set up PATH, at least on windows?

Re: Free-threaded CPython is ready to experiment with

#283

Post by dgfitz »

stavros wrote: post #259
ahartmetz wrote: post #246

Earlier quoted context omitted.

Is that because the compiler failed with "foo.h not found" or the build system said "libfoo not found"? CMake is most common and it will tell you. Worst case it's difficult to derive the package name from the name in the diagnostic. It's not great, but usually not a big deal neither IME. Typically a couple of minutes to e.g. find that required libSDL2 addon module or whatever, if there is that kind of problem at all.

Yes it is, and it's usually such a big deal for me that I just don't use that software. I don't have time to go through a loop of "what's the file name? What package is it in? Install, repeat". This is by far the worst experience I've had with any language. Python has been a breeze in comparison.

I’m not going to refute your points. If you’re going to wear rose-tinted glasses about all of the bad parts about python, that’s fine, I also like python.

Re: Free-threaded CPython is ready to experiment with

#284

Post by stavros »

dgfitz wrote: post #283
stavros wrote: post #259

Earlier quoted context omitted.

Yes it is, and it's usually such a big deal for me that I just don't use that software. I don't have time to go through a loop of "what's the file name? What package is it in? Install, repeat". This is by far the worst experience I've had with any language. Python has been a breeze in comparison.

I’m not going to refute your points. If you’re going to wear rose-tinted glasses about all of the bad parts about python, that’s fine, I also like python.

What's rose-tinted about "one of them downloads dependencies automatically, the other one doesn't"?

Re: Free-threaded CPython is ready to experiment with

#285

Post by simonw »

arp242 wrote: post #239
simonw wrote: post #126

Earlier quoted context omitted.

"Give me a single command I can run. Always. For any project. And that always works." pipx install X

Right so; I'll try that next time. Thanks. I just go by the very prominent "pip install X" on every pypi page (as well as "pip install .." in many READMEs).

Yeah, totally understand that - pipx is still pretty poorly known by people who are active in Python development!

A few of my READMEs start like this: https://github.com/simonw/paginate-json?tab=readme-ov-file#i...

    ## Installation

    pip install paginate-json

    Or use pipx (link to pipx site)

    pipx install paginate-json
But I checked and actually most them still don't even mention it. I'll be fixing that in the future.

Re: Free-threaded CPython is ready to experiment with

#286

Post by Galanwe »

eigenvalue wrote: post #12

Really excited for this. Once some more time goes by and the most important python libraries update to support no GIL, there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects. It's also a good opportunity for new and more actively maintained projects to take market share from older and more established libraries if th…

> It's going to be amazing to saturate all the cores on a big machine using simple threads instead of dealing with the massive overhead and complexity and bugs of using something like multiprocessing.

I'm saturating 192cpu / 1.5TBram machines with no headache and straightforward multiprocessing. I really don't see what multithreading will bring more.

What are these massive overheads / complexity / bugs you're talking about ?

Re: Free-threaded CPython is ready to experiment with

#287

Post by mondrian »

zarzavat wrote: post #277
whoiscroberts wrote: post #173

Earlier quoted context omitted.

Optional static typing, not really. Those type hints are not used at runtime for performance. Type hint a var as a string then set it to an init, that code still gonna try to execute.

> Those type hints are not used at runtime for performance. This is not a requirement for a language to be statically typed. Static typing is about catching type errors before the code is run. > Type hint a var as a string then set it to an int, that code still gonna try to execute. But it will fail type checking, no?

The critique is that "static typing" is not really the right term to use, even if preceded by "optional". "Type hinting" or "gradual typing" maybe.

In static typing the types of variables don't change during execution.

Re: Free-threaded CPython is ready to experiment with

#288

Post by indigodaddy »

indigodaddy wrote: post #162
eigenvalue wrote: post #123

Earlier quoted context omitted.

I personally optimize more for development time and overall productivity in creating and refactoring, adding new features, etc. I'm just so much faster using Python than anything else, it's not even close. There is such an incredible world of great libraries easily available on pip for one thing. Also, I've found that ChatGPT/Claude3.5 are much, much smarter and better at Python than they are at C++ or Rust. I can us…

Ever messed about with Claude and php?

Why the downvotes? Totally serious question. Jesus Christ HN

Re: Free-threaded CPython is ready to experiment with

#290

Post by zarzavat »

mondrian wrote: post #287
zarzavat wrote: post #277

Earlier quoted context omitted.

> Those type hints are not used at runtime for performance. This is not a requirement for a language to be statically typed. Static typing is about catching type errors before the code is run. > Type hint a var as a string then set it to an int, that code still gonna try to execute. But it will fail type checking, no?

The critique is that "static typing" is not really the right term to use, even if preceded by "optional". "Type hinting" or "gradual typing" maybe. In static typing the types of variables don't change during execution.

If there’s any checking of types before program runs then it’s static typing. Gradual typing is a form of static typing that allows you to apply static types to only part of the code.

I’m not sure what you mean by variables not changing types during execution in statically typed languages. In many statically typed languages variables don’t exist at runtime, they get mapped to registers or stack operations. Variables only exist at runtime in languages that have interpreters.

Aside from that, many statically typed languages have a way to declare dynamically typed variables, e.g. the dynamic keyword in C#. Or they have a way to declare a variable of a top type e.g. Object and then downcast.

Post reply on HN