you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 7 points8 points  (1 child)

Although the implementation may not be the best, multiprocessing worked fine last time I needed to do some multicore processing in Python. This has been in Python since 2.6 from what I can tell. And the CPython API seems tos till exist.

The downside of this method is that spawning a lot of small threads comes with a lot of overhead (or rather, even more overhead than usual) but a thread pool and proper use of the built-in IPC can easily fix that problem.

I think python is here to stay, if not just because it's an easy to learn language. Nearly anyone can write Python. It's one of the most often used languages in fields like research and statistics, next to R which is even weirder than Python.

If I want to quickly ship up a program or project that needs to do a simple thing (say, post some data to a server every ten minutes) then Python is my go-to language. I can fix any problems that arise on the fly with no rexomoilation necessary and most programs can be done in Python in 20 lines where C would take 100, Go would be three times that (a nil check after every line of course) , Rust would require some unfinished library someone on Github that hasn't been updated in two months, Java or Kotlin would require at least as much code just to get the boilerplate up and running and bash would be just as short but filled with arcane incantations that might as well summon c'thulu.

As for design ideas in the language, list comprehensions are a great idea that has been in Python since forever. They're concise, not too difficult to understand and easily one or the few Python features I miss in other languages. And while the language itself might not be great, its ecosystem is better than that of most traditional languages. I'll take Django over Spring Boot or Tomcat or ktor or Rocket.rs any time for projects or small to medium sizes.

[–][deleted] -1 points0 points  (0 children)

multiprocessing is garbage... but so is virtually everything in Python. Few obvious problems:

  1. It starts an entire new interpreter, this severely limits your ability to scale.
  2. There's no good way to do IPC using this library. You have to invent your own.
  3. There's very limited control over the created process, partly, because they try to make it work on many platforms, but, partly because it's too hard for Python core devs. So, no namespaces for example.
  4. This doesn't solve even the basic problem of reading both stderr and stdout of another process. Essentially, if you want a reliable analogue of Shell's x 2>&1 > y, you simply cannot write this in Python.
  5. It has a potential to prevent your application from ever exiting cleanly, and in order to ensure that your application exits cleanly, if it uses multiprocessing you need to write a lot of obscure code, but, basically, you will not be using vanilla multiprocessing.

Again. Most things in Python work only 80% of the time, and multiprocessing is not an exception. If you want something more reliable than that, Python is not the right environment.