• lime!
    link
    fedilink
    English
    519 days ago

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

      • lime!
        link
        fedilink
        English
        118 days ago

        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.

        • @WolfLink@sh.itjust.works
          link
          fedilink
          8
          edit-2
          8 days ago

          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.

    • @danhab99@programming.dev
      link
      fedilink
      99 days ago

      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.

      • lime!
        link
        fedilink
        English
        78 days ago

        nothing about any of those libraries dictates an OO approach.

          • Meh, even Java has decent FP paradigm support these days. Just because you can do everything in an OO way in Java doesn’t mean you need to.

        • @danhab99@programming.dev
          link
          fedilink
          08 days ago

          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)

          • lime!
            link
            fedilink
            English
            48 days ago

            the thread library is aping the posix thread interface with python semantics.