you are viewing a single comment's thread
view the rest of the comments
[–] 52 points 1 year ago (2 children)

python has way too many ways to do that. asyncio, future, thread, multiprocessing...

  • source
  • parent
  • hideshow 4 child comments
  • [–] 41 points 1 year ago (1 child)

    Of the ways you listed the only one that will actually take advantage of a multi core CPU is multiprocessing

  • source
  • parent
  • hideshow 2 child comments
  • [–] 11 points 1 year ago (1 child)

    yup, that's true. most meaningful tasks are io-bound so "parallel" basically qualifies as "whatever allows multiple threads of execution to keep going". if you're doing numbercrunching in pythen without a proper library like pandas, that can parallelize your calculations, you're doing it wrong.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 8 points 1 year ago* (1 child)

    I’ve used multiprocessing to squeeze more performance out of numpy and scipy. But yeah, resorting to multiprocessing is a sign that you should be dropping into something like Rust or a C variant.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 9 points 1 year ago (1 child)

    I've always hated object oriented multi threading. Goroutines (green threads) are just the best way 90% of the time. If I need to control where threads go I'll write it in rust.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago (2 children)

    nothing about any of those libraries dictates an OO approach.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 0 points 1 year ago (1 child)

    If I have to put a thread object in a variable and call a method on it to start it then it's OO multi threading. I don't want to know when the thread spawns, I don't want to know what code it's running, and I don't want to know when it's done. I just want shit to happen at the same time (90% of the time)

  • source
  • parent
  • hideshow 2 child comments