3 ms·

IMHO majority of Python software doesn't use threads because it is easier to write single threaded code (for many reasons), not because of GIL.

metadat 4y ago
In Golang you can spawn a green thread on any function call with a single keyword: `go'. The ergonomics are such that it's not difficult to use. Why can't or shouldn't we have a mechanism comparably fantastic and easy to use in Python?
- Twirrim 4y ago
  https://docs.python.org/3/library/concurrent.futures.html https://docs.python.org/3/library/concurrent.futures.html sort of gives you that, syntax works with threads or processes.
- metadat 4y ago
  @Twirrim How would you rate the user experience of the concurrent.futures package compared to the golang `go' keyword? It is architecturally comparable to async Javascript programming, which imho is a shoehorn solution.
- lmm 4y ago
  Because making it easy to write C/C++ extensions that work the way you expect (including for things like passing a Python callback to a C/C++ library) has always been a priority for Python in a way that it isn't for Golang?
  - liuliu 4y ago
    Any C/C++ extensions that wants to enable more efficient Python has to learn GIL and how to manipulate that as well. Including not limited to: how to give up GIL (so that other Python code can progress); how to prepare your newly initiated threads to be Python GIL friendly etc. Personally, GIL is more surprising to me when interop with Python.
    - lmm 4y ago
      > Any C/C++ extensions that wants to enable more efficient Python has to learn GIL and how to manipulate that as well. Including not limited to: how to give up GIL (so that other Python code can progress); how to prepare your newly initiated threads to be Python GIL friendly etc. Sure, but the easy cases are easy (in particular, you can usually do nothing and it will be correct but slow, which is much better than fast but incorrect) and the hard cases are possible. > Personally, GIL is more surprising to me when interop with Python. Any GCed language, including Go, will oblige you to integrate with its APIs if you want to handle complex cases correctly.

metadat 4y ago

In Golang you can spawn a green thread on any function call with a single keyword: `go'. The ergonomics are such that it's not difficult to use. Why can't or shouldn't we have a mechanism comparably fantastic and easy to use in Python?

Twirrim 4y ago
https://docs.python.org/3/library/concurrent.futures.html https://docs.python.org/3/library/concurrent.futures.html sort of gives you that, syntax works with threads or processes.
metadat 4y ago
@Twirrim How would you rate the user experience of the concurrent.futures package compared to the golang `go' keyword? It is architecturally comparable to async Javascript programming, which imho is a shoehorn solution.
lmm 4y ago
Because making it easy to write C/C++ extensions that work the way you expect (including for things like passing a Python callback to a C/C++ library) has always been a priority for Python in a way that it isn't for Golang?
- liuliu 4y ago
  Any C/C++ extensions that wants to enable more efficient Python has to learn GIL and how to manipulate that as well. Including not limited to: how to give up GIL (so that other Python code can progress); how to prepare your newly initiated threads to be Python GIL friendly etc. Personally, GIL is more surprising to me when interop with Python.
  - lmm 4y ago
    > Any C/C++ extensions that wants to enable more efficient Python has to learn GIL and how to manipulate that as well. Including not limited to: how to give up GIL (so that other Python code can progress); how to prepare your newly initiated threads to be Python GIL friendly etc. Sure, but the easy cases are easy (in particular, you can usually do nothing and it will be correct but slow, which is much better than fast but incorrect) and the hard cases are possible. > Personally, GIL is more surprising to me when interop with Python. Any GCed language, including Go, will oblige you to integrate with its APIs if you want to handle complex cases correctly.