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

41–50 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#41

Post by discreteevent »

I remember back around 2007 all the anxious blog posts about the free lunch (Moore's law) being over. Parallelism was mandatory now. We were going to need exotic solutions like software transactional memory to get out of the crisis (and we could certainly forget about object orientation).

Meanwhile what takes the crown? - Single threaded python.

(Well, ok Rust looks like it's taking first place where you really need the speed and it does help parallelism without requiring absolute purity)

Re: Free-threaded CPython is ready to experiment with

#42

Post by baq »

hot_gril wrote: post #39
GTP wrote: post #11

Earlier quoted context omitted.

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system.…

I think static typing is a waste of time, but given that you want it, I can see why you wouldn't want to use Python. Its type-checking is more half-baked and cumbersome than other languages, even TS.

Typescript is pretty much the gold standard, it’s amazing how much JavaScript madness you can work around just on the typechecking level.

IMHO Python should shamelessly steal as much typescript’s typing as possible. It’s tough since the Microsoft typescript team is apparently amazing at what they do so for now it’s a very fast moving target but some day…

Re: Free-threaded CPython is ready to experiment with

#43

Post by wiseowise »

yosefk wrote: post #10
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++.

If Python's dependency management is better than anything, it's better than C++'s. Python has pip and venv. C++ has nothing (you could say less than nothing since you also have ample opportunity for inconsistent build due to mismatching #defines as well as using the wrong binaries for your .h files and nothing remotely like type-safe linkage to mitigate human error. It also has an infinite number of build systems whe…

> If Python's dependency management is better than anything, it's better than C++'s.

That’s like the lowest possible bar to clear.

Re: Free-threaded CPython is ready to experiment with

#44

Post by hot_gril »

Sparkyte wrote: post #23

My 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.

What are the common use cases for threading in Python? I feel like that's a lower level tool than most Python projects would want, compared to asyncio or multiprocessing.Pool. JS is the most comparable thing to Python, and it got pretty darn far without threads.

Re: Free-threaded CPython is ready to experiment with

#45

Post by BugsJustFindMe »

hot_gril wrote: post #44
Sparkyte wrote: post #23

My 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.

What are the common use cases for threading in Python? I feel like that's a lower level tool than most Python projects would want, compared to asyncio or multiprocessing.Pool. JS is the most comparable thing to Python, and it got pretty darn far without threads.

Working with asyncio sucks when all you want is to be able to do some things in the background, possibly concurrently. You have to rewrite the worker code using those stupid async await keywords. It's an obnoxious constraint that completely breaks down when you want to use unaware libraries. The thread model is just a million times easier to use because you don't have to change the code.

Re: Free-threaded CPython is ready to experiment with

#46

Post by GTP »

hot_gril wrote: post #40
VeejayRampay wrote: post #37

Earlier quoted context omitted.

python will never be "properly typed" what it has is "type hints" which is way to have richer integration with type checkers and your IDE, but will never offer more than that as is

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 function does just by looking at it, you can't even know if the function is correct (in the sense that will not raise an exception).

Re: Free-threaded CPython is ready to experiment with

#48

Post by bongodongobob »

hot_gril wrote: post #44
Sparkyte wrote: post #23

My 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.

What are the common use cases for threading in Python? I feel like that's a lower level tool than most Python projects would want, compared to asyncio or multiprocessing.Pool. JS is the most comparable thing to Python, and it got pretty darn far without threads.

Same as any other language. Separating UI from calculations is my most common need for it.

Re: Free-threaded CPython is ready to experiment with

#49

Post by hot_gril »

BugsJustFindMe wrote: post #45
hot_gril wrote: post #44

Earlier quoted context omitted.

What are the common use cases for threading in Python? I feel like that's a lower level tool than most Python projects would want, compared to asyncio or multiprocessing.Pool. JS is the most comparable thing to Python, and it got pretty darn far without threads.

Working with asyncio sucks when all you want is to be able to do some things in the background, possibly concurrently. You have to rewrite the worker code using those stupid async await keywords. It's an obnoxious constraint that completely breaks down when you want to use unaware libraries. The thread model is just a million times easier to use because you don't have to change the code.

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?

Re: Free-threaded CPython is ready to experiment with

#50

Post by elijahbenizzy »

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-bound? Cool, let's launch another thread. Oh, the first few threads were I/O-bound? Cool, let's use in-thread coroutines".

Probably not feasible for a myriad of reasons, but even a more fluid programming model could be really cool (similar interfaces with a quick swap between?).

Post reply on HN