GVR, you are sorely missed, though I hope you are enjoying life.
Free-threaded CPython is ready to experiment with
61–70 of 398 posts
Re: Free-threaded CPython is ready to experiment with
#62Earlier quoted context omitted.
Non-blocking HTTP requests is an extremely common need, for instance. Why the hell did we need to reinvent special asyncio-aware request libraries for it? It's absolute madness. Thread pools are much easier to work with. > where some framework is probably already handling the main event loop This is both not really true and also irrelevant. When you need a flask (or whatever) request handler to do parallel work, asyn…
Non-blocking HTTP request is the bread and butter use case for asyncio. Most JS projects are doing something like this, and they don't need to manage threads for it. You want to manage your own thread pool for this, or are you going to spawn and kill a thread every time you make a request?
> Non-blocking HTTP request is the bread and butter use case for asyncio
And the amount of contorting that has to be done for it in Python would be hilarious if it weren't so sad.
> Most JS projects
I don't know what JavaScript does, but I do know that Python is not JavaScript.
> You want to manage your own thread pool for this...
In Python, concurrent futures' ThreadPoolExecutor is actually nice to use and doesn't require rewriting existing worker code. It's already done, has a clean interface, and was part of the standard library before asyncio was.
Re: Free-threaded CPython is ready to experiment with
#63Earlier quoted context omitted.
It is properly typed: it has dynamic types :)
Then we have very different ideas of what proper typing is :D Look at this function, can you tell me what it does? def plus(x, y): return x+y If your answer is among the lines of "It returns the sum x and y" then I would ask you who said that x and y are numbers. If these are strings, it concatenates them. If instead you pass a string and a number, you will get a runtime exception. So not only you can't tell what a f…
Both Haskell and OCaml can raise exceptions for you, yet most people would say that they are properly typed.
The plus function you wrote is not more confusing than any generic function in a language that supports that.
Re: Free-threaded CPython is ready to experiment with
#64Does anyone know if there is more serious single threaded performance degradation (more than a few percent for instance)? I couldn't find any benchmarks, just some generic reassurance that everything is fine.
Right now there is a significant single-threaded performance cost. Somewhere from 30-50%. Part of what my colleague Ken Jin and others are working on is getting back some of that lost performance by applying some optimizations. Expect single-threaded performance to improve for Python 3.14 next year.
To be honest, that seems a lot. Even today a lot of code is single-threaded, and this performance hit will also affect a lot of code running in parallel today.
There have been patches to remove the GIL going back to the 90s and Python 1.5 or thereabouts. But the performance impact has always been the show-stopper.
Re: Free-threaded CPython is ready to experiment with
#65Earlier quoted context omitted.
Asyncio is designed for things like webservers or UIs where some framework is probably already handling the main event loop. What are you doing where you just want to run something else in the background, and IPC isn't good enough?
Non-blocking HTTP requests is an extremely common need, for instance. Why the hell did we need to reinvent special asyncio-aware request libraries for it? It's absolute madness. Thread pools are much easier to work with. > where some framework is probably already handling the main event loop This is both not really true and also irrelevant. When you need a flask (or whatever) request handler to do parallel work, asyn…
You don’t? concurrent.futures.ThreadPoolExecutor can get a lot done without touching async code.
Re: Free-threaded CPython is ready to experiment with
#66Earlier quoted context omitted.
Non-blocking HTTP requests is an extremely common need, for instance. Why the hell did we need to reinvent special asyncio-aware request libraries for it? It's absolute madness. Thread pools are much easier to work with. > where some framework is probably already handling the main event loop This is both not really true and also irrelevant. When you need a flask (or whatever) request handler to do parallel work, asyn…
You don’t? concurrent.futures.ThreadPoolExecutor can get a lot done without touching async code.
I am a big advocate for ThreadPoolExecutor. I'm saying it's superior to asyncio. The person I'm responding to was asking why use threads when you can use asyncio instead.
Re: Free-threaded CPython is ready to experiment with
#67Earlier quoted context omitted.
Not sure this is still a valid critic of Python in 2024. Between pip, poetry and pyproject.toml, things are now quite good IMHO.
I guess that depends from your perspective. I'm not a Python developer, but like many people I do want to run Python programs from time to time. I don't really know Rust, or Cargo, but I never have trouble building any Rust program: "cargo build [--release]" is all I need to know. Easy. Even many C programs are actually quite easy: "./configure", "make", and optionally "make install". "./configure" has a nice "--help…
"I don't want a bunch of venvs"
That's your problem right there.
Virtual environments are the Python ecosystem's solution to the problem of wanting to install different things on the same machine that have different conflicting requirements.
If you refuse to use virtual environments and you install more than one separate Python project you're going to run into conflicting requirements and it's going to suck.
Have you tried pipx? If you're just installing Python tools (and not hacking on them yourself) it's fantastic - it manages separate virtual environments for each of your installations without you having to think about them (or even know what a virtual environment is).
Re: Free-threaded CPython is ready to experiment with
#68My body is ready. I love python because the ease of writing and logic. Hopefully the more complicated free-threaded approach is comprehensive enough to write it like we traditionally write python. Not saying it is or isn't I just haven't dived enough into python multithreading because it is hard to put those demons back once you pull them out.
The semantic changes are negligible for authors of Python code. All the complexity falls on the maintainers of the CPython interpreter and on authors of native extension modules.
Well, I'm not looking forward to the day when I upgrade my Python and suddenly I have to debug a ton of fun race conditions.
Re: Free-threaded CPython is ready to experiment with
#69Earlier quoted context omitted.
Non-blocking HTTP request is the bread and butter use case for asyncio. Most JS projects are doing something like this, and they don't need to manage threads for it. You want to manage your own thread pool for this, or are you going to spawn and kill a thread every time you make a request?
> Non-blocking HTTP request is the bread and butter use case for asyncio And the amount of contorting that has to be done for it in Python would be hilarious if it weren't so sad. > Most JS projects I don't know what JavaScript does, but I do know that Python is not JavaScript. > You want to manage your own thread pool for this... In Python, concurrent futures' ThreadPoolExecutor is actually nice to use and doesn't r…
I feel you. I know asyncio is "the future", but I usually just want to write a background task, and really hate all the gymnastics I have to do with the color of my functions.
Re: Free-threaded CPython is ready to experiment with
#70Earlier quoted context omitted.
The semantic changes are negligible for authors of Python code. All the complexity falls on the maintainers of the CPython interpreter and on authors of native extension modules.
Well, I'm not looking forward to the day when I upgrade my Python and suddenly I have to debug a ton of fun race conditions.
It's kept behind a flag. Hopefully will be forever.