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

361–370 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#361

Post by kaba0 »

skissane wrote: post #353
lyu07282 wrote: post #352

Earlier quoted context omitted.

This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process. Just because it's a child process (by default it's a forked process!) not a thread, doesn't mean it can not have shared resources. It can lead to deadlocks, stuck processes, all kinds of resource leaks, data and stream cor…

> This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process. If you have an open file or network connection, the kernel is guaranteed to close it for you when the process is killed (assuming it hasn't passed the fd/socket to a subprocess, etc). That's not a matter of opinion. Yes,…

Different programming languages have different guarantees when it comes to threads. If IO is hidden behind object semantics, objects aren’t killed by “killing” a thread, and they can be gracefully terminated when they are deemed to no longer be in use.

Re: Free-threaded CPython is ready to experiment with

#362

Post by pletnes »

__MatrixMan__ wrote: post #292
pletnes wrote: post #274

Earlier quoted context omitted.

This is what we used to have and it was much worse. Source: lived that life 10-15 y ago.

15y ago I was using apt-get to manage my c++ dependencies with no way of keeping track of which dependency went with which project. It was indeed pretty awful. Now when I cd into a project, direnv + nix notices the dependencies that that project needs and makes them available, whatever their language. When I cd into a different project, I get an entirely different set of dependencies. There's pretty much nothing inst…

Valid points. I was also thinking about apt install-ing some C library, try to pip install a package, have it fail to build, look for headers/debug packages in apt, set LD_LIBRARY… you know. It hurts, a lot.

And yet, python is a fantastic language because it’s the remote control to do the heavy, complex, low-level, high-performance stuff with relative ease.

Re: Free-threaded CPython is ready to experiment with

#363

Post by kaba0 »

throwaway81523 wrote: post #325
pansa2 wrote: post #248

Earlier quoted context omitted.

Yes, this is similar to how Go works. IIRC the same approach was available in Python as a library, “greenlet”, but Python’s core developers rejected it in favour of `async`/`await`.

The Python community seems to have a virulent hatred of threads. I don't understand the reason. Yes there are hazards but you can code in a style that avoids them. With something like BEAM you can even enforce the style. Async/await of course introduce their own hazards.

I think it wouldn’t work as nicely with python, which deeply builds on C FFI. Java has a different history, and almost the whole ecosystem is pure, making it able to take advantage of it.

Re: Free-threaded CPython is ready to experiment with

#364

Post by __MatrixMan__ »

pletnes wrote: post #362
__MatrixMan__ wrote: post #292

Earlier quoted context omitted.

15y ago I was using apt-get to manage my c++ dependencies with no way of keeping track of which dependency went with which project. It was indeed pretty awful. Now when I cd into a project, direnv + nix notices the dependencies that that project needs and makes them available, whatever their language. When I cd into a different project, I get an entirely different set of dependencies. There's pretty much nothing inst…

Valid points. I was also thinking about apt install-ing some C library, try to pip install a package, have it fail to build, look for headers/debug packages in apt, set LD_LIBRARY… you know. It hurts, a lot. And yet, python is a fantastic language because it’s the remote control to do the heavy, complex, low-level, high-performance stuff with relative ease.

I agree. I want to help save python from its packaging problems because it has so much traction out there (for good reason). People in this forum might be ok jumping ship to rust or whatever but most python users are students, scientists, business types... They're not going to learn rust and I don't think we benefit from leaving them behind.

I wish there was a standard interface that tools like pip could use to express their non-python needs such that some other tool can meet those needs and then hand the baton back to pip once they are met. Poetry2nix is an example of such a collaboration. (I'm not trying to be a nix maximalist here, it's just that it's familiar).

The python community is large enough to attempt to go it alone, but many other language communities are not. I think we'd see faster language evolution if we asked less of them from a packaging perspective:

> focus on making the language great. Provide a way to package deps in that language, and use _____ to ask for everything else.

Apt and brew and snap and whatever else (docker? K8s?) could be taught to handle such requests in a non alter-your-whole-system kind of way.

Re: Free-threaded CPython is ready to experiment with

#365

Post by kaba0 »

__MatrixMan__ wrote: post #83
jolux wrote: post #9

Earlier quoted context omitted.

The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.

Python's dependency management sucks because they're audacious enough to attempt packaging non-python dependencies. People always bring Maven up as a system that got it right, but Maven only does JVM things. I think the real solution here is to just only use python dependency management for python things and to use something like nix for everything else.

There is no way to manage non-hosted dependencies, though, in a cross-platform way. Something attempting it is often worse than nothing, on a distro that has different assumptions — e.g. every package manager that downloads a dynamic executable will fail on NixOS, and gives no easy way to hook into how those get executed.

Re: Free-threaded CPython is ready to experiment with

#366

Post by kaba0 »

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.

That’s not really “the definition”. Different type systems can express different properties about objects, and there are absolutely cases that something changes about a type.

E.g. in structural typing, adding a new field will change the type to a subtype. Will it make any structural typed language non-static?

Re: Free-threaded CPython is ready to experiment with

#367

Post by kaba0 »

mondrian wrote: post #299
zarzavat wrote: post #290

Earlier quoted context omitted.

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…

Python is dynamically typed because it type-checks at runtime, regardless of annotations or what mypy said.

Is java dynamically typed as well, then? It does reify generics, so only some part is type checked, what is the level at which it is statically/dynamically typed?

Re: Free-threaded CPython is ready to experiment with

#368

Post by elijahbenizzy »

bastawhiz wrote: post #111
elijahbenizzy wrote: post #50

I'm really curious to see how this will work with async. There's a natural barrier (I/O versus CPU-bound code), which isn't always a perfect distinction. I'd love to see a more fluid model between the two -- E.G. if I'm doing a "gather" on CPU-bound coroutines, I'm curious if there's something that can be smart enough to JIT between async and multithreaded implementations. "Oh, the first few tasks were entirely CPU-b…

I think you'd be hard pressed to find a workload where that behavior needs to be generalized to the degree you're talking. If you're serving HTTP requests, for instance, simply serving each request on its own thread with its own event loop should be sufficient at scale. Multiple requests each with CPU-bound tasks will still saturate the CPUs. Very little code teeters between CPU-bound and io-bound while also serving…

Interesting. I don't disagree, in general, but I actually have worked with a lot of applications that like to do this. Specifically in the world of ML/AI inference there's a lot of moving between external querying of data (features) and internal/external querying of models. With recommendation systems it is often worse -- gather large data, run a computation on it, filter it, get a bulk API request, score it with a model, etc...

This is exactly where I'd like to see it.

I'd like to simultaneously:

1. Call out to external APIs and not run any overhead/complexity of creating/managing threads 2. Call out to a model on a CPU and not have it block the event loop (I want it to launch a new thread and have that be similar to me) 3. Call out to a model on a GPU, ditto

And use the observed resource CPU/GPU usage to scale up nicely with an external horizontal scaling system.

So it might be that the async API is a lot easier to use/ergonomic then threads. I'd be happy to handle thread-safety (say, annotating routines), but as you pointed out, there are underlying framework assumptions that make this complicated.

The solution we always used is to separate out the CPU-bound components from the IO-bound components, even onto different servers or sidecar processes (which, effectively, turn CPU-bound into IO-bound operations). But if they could co-exist happily, I'd be very excited. Especially if they could use a similar API as async does.

Re: Free-threaded CPython is ready to experiment with

#369

Post by westurner »

Will there be an effort to encourage devs to add support for free-threaded Python like for Python 3 [1] and for Wheels [2]?

Is there a cibuildwheel / CI check for free-threaded Python support?

Is there already a reason not to have Platform compatibility tags for free-threaded cpython support? https://packaging.python.org/en/latest/specifications/platfo...

Is there a hame - a hashtaggable name - for this feature to help devs find resources to help add support?

Can an LLM almost port in support for free-threading in Python, and how should we expect the tests to be insufficient?

"Porting Extension Modules to Support Free-Threading" https://py-free-threading.github.io/porting/

[1] "Python 3 "Wall of Shame" Becomes "Wall of Superpowers" Today" https://news.ycombinator.com/item?id=4907755

[2] https://pythonwheels.com/

(Edit)

Compatibility status tracking: https://py-free-threading.github.io/tracking/

Re: Free-threaded CPython is ready to experiment with

#370

Post by westurner »

westurner wrote: post #369

Will there be an effort to encourage devs to add support for free-threaded Python like for Python 3 [1] and for Wheels [2]? Is there a cibuildwheel / CI check for free-threaded Python support? Is there already a reason not to have Platform compatibility tags for free-threaded cpython support? https://packaging.python.org/en/latest/specifications/platfo... Is there a hame - a hashtaggable name - for this feature to he…

Install commands from https://py-free-threading.github.io/installing_cpython/ :

  sudo dnf install python3.13-freethreading

  sudo add-apt-repository ppa:deadsnakes
  sudo apt-get update
  sudo apt-get install python3.13-nogil

  conda create -n nogil -c defaults -c ad-testing/label/py313_nogil python=3.13

  mamba create -n nogil -c defaults -c ad-testing/label/py313_nogil python=3.13
TODO: conda-forge ?, pixi
Post reply on HN