This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Python is finally looking to make GIL (Global Interpreter Lock) optional, so Pythonists can finally write multithreaded code. There’s an HN Thread here [https://news.ycombinator.com/item?id=36913328]
One interesting thing is the denial that GIL is was a set back for Python. For example, comments like these:
> Who needs No-GIL when we have asyncio and multiprocessing packages ?
> sharing state between threads is such a narow niche use case, this pattern is practically solved by memcached/redis for larger scale python based systems
That’s so much more work, overhead and infrastructure than just changing a map
-> pmap
!
It sounds like something a bit similar to https://en.wikipedia.org/wiki/Stockholm_syndrome, if they admit now that GIL is bad they would have to admit they’ve been badly mistreated by it for years.
For well over a decade I've listened to Pythonists explain the GIL as a feature to me... Good for them. Maybe now they'll consider dropping the mantra "it doesn't need to be fast/performant".
I dislike python's syntax and space-based identation. I hope they'll fix that soon too. Especially lambda
syntax and requirements for commas (wait, wasn't it supposed to be whitespace delimited?).
def my_func1():
return ((1,2),
(3,4))
def my_func2():
return ((1,2)
(3,4))
It turns out that my_func2
would crash because it would think that 3,4
are arguments for a function call... and this comma is really easy to miss.
Error string:
SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma?
I don't use Python much. But IMO there should be languages that are easy to reason about computationally, quick to write, easy to learn etc. That's why Python, JS, Ruby, Lua etc. exist. Why use Python for tasks that require multi threading? just seems like the wrong tool for the job?
imho, Clojure is no more difficult a language and does have multithreading. To each their own, but I see no reason why Python couldn't also have multithreading and still be easy to use (especially if you don't use the multithreading facilities). 🤷
Because everything that Python uses (C libraries included) now has to throw away the GIL assumption. That's a massively breaking change that introduces very hard problems. Languages don't exist in a vacuum. There are specific usage contexts and assumptions surrounding them. Python is scripting over C libraries. The point here is to have a very straight forward language that anyone can pick up quickly. The value prop here is that computational complexity is not a consideration. Clojure is a functional Lisp over the JVM. It's a language for concurrent information processing. That's decidedly not the same use case as Python. It has a completely different set of tradeoffs. IMO it's a good thing that we have meaningfully different languages to choose from. And I assume that the people who have chosen Python or provide C libraries for Python have done so deliberately. For me the attempt to phase out GIL because "multithreading is good" is a red flag (as if there are no tradeoffs). It will break stuff. Lots of stuff. And I really feel for all the library and application maintainers who will be pressed to migrate, manage and fix their stuff.