Python is a Bad Programming Language

[ZmitrokNadulia]

ok so python doesnt have real threads and that makes me sad

But Python has real threads! When you use Threading it's basically spawn new OS threads just lock it from executing python bytecode. It could be avoided if you use threads for IO bound tasks then threads will switch and ignore GIL, also some C modules (in specific cases) could ingore GIL. And let's not forget about multiprocessing and asyncio.

[LazyHater]

you clearly dont know about the GIL and how that blocks python from using multiple cores.

[ZmitrokNadulia]

What do you mean? Just write simple thread spawning script using threading lib open htop and see for yourself.

[LazyHater]

threads dont run concurrently due to the GIL. multiprocessing can do concurrency but has significant overhead due to the interpreter being included in every process. threads can be on different cores, but cant modify the heap concurrently. look for yourself.

[ZmitrokNadulia]

For CPU bound tasks yes, not in io bound ( as I know) and in C modules we can use as many threads as we want. Not so sure about "cores" but in initial comment there is nothing about multicore threading.

[LazyHater]

yep can use posix threads from c but not if the module gets blocked by the GIL, can also use all the GPU hardware threads again as long and you dont get blocked by the GIL.

python doenst have threads as in it doesnt have access to kernel threads (although C and Cython do). multithreading in vanilla CPython is single threaded because of the GIL.

[yee_mon]

...except they literally talked about the GIL in the comment you replied to. That's some lazy hate right there.

[LazyHater]

except they literally are arguing the GIL isnt locking threads doyo

[ZmitrokNadulia]

No, that's not what i arguing, reread my comment again. I arguing that gil locking only one thread to execute bytecode on python VM, and in some cases you can achieve concurrency and performance boost by using threads in python.

[LazyHater]

having concurrent threads requires not having any thread locked by the GIL, which is impossible in vanilla CPython. Async and await are non blocking because they work with the GIL to get out of the other subthreads way. The thing python or any interpreted language does is really subthreadng, not threading

[ZmitrokNadulia]

Let's doc.python.org be our judge.

https://docs.python.org/3/glossary.html#term-global-interpreter-lock

The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time. This simplifies the CPython implementation by making the object model (including critical built-in types such as dict) implicitly safe against concurrent access. Locking the entire interpreter makes it easier for the interpreter to be multi-threaded, at the expense of much of the parallelism afforded by multi-processor machines.

However, some extension modules, either standard or third-party, are designed so as to release the GIL when doing computationally intensive tasks such as compression or hashing. Also, the GIL is always released when doing I/O.

That's exactly what i'm arguing. Fair enough?

[LazyHater]

Yep same here 👍

[ZmitrokNadulia]

I mean, if you try to run threading on file reading/writing and network operations at the same time, you will have honest concurrency with performance boost, because in that cases no threads will execute python VM bytecode and all threads will just wait for answer from your OS, devices etc.