Python Language Summit: Python Without the GIL

Re:Python Language Summit: Python Without the GIL by klibertp on Thursday May 12, 2022 @05:59AM (#31351588)

What about all the scripts and programs that depend on the GIL to give correct results - often without even their authors knowing about it? I guess making this opt-in with a compiler flag is ok, but I would be very, very careful about making it the default. If that ever happens, we will be one Python interpreter upgrade from Y2K-like disaster...

[ Parent | on HN ]

Re:Python Language Summit: Python Without the GIL by js2 on Thursday May 12, 2022 @09:16AM (#31353669)

FUD. This effort is very carefully designed so that such programs continue to operate correctly.

https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...

[ Parent | on HN ]

Re:Python Language Summit: Python Without the GIL by danbala on Thursday May 12, 2022 @06:21AM (#31351785)

almost like people should test their code before using a new python version in production.

[ Parent | on HN ]

Re:Python Language Summit: Python Without the GIL by klibertp on Thursday May 12, 2022 @06:28AM (#31351851)

That's the problem: the kind of issues the GIL prevents is notoriously hard to reproduce and debug. It would probably pass 90% of the test suites out there, unless you wrote yours with multi-threading in mind. Same for empirical tests by QA teams - they rarely cause enough load on the system for the bugs to surface. I might be too pessimistic here, but this really looks to me like a disaster waiting to happen...

[ Parent | on HN ]

Re:Python Language Summit: Python Without the GIL by gcbirzan on Thursday May 12, 2022 @06:30AM (#31351869)

Because concurrency issues are notoriously easy to catch.

[ Parent | on HN ]

Re:Python Language Summit: Python Without the GIL by alkonaut on Thursday May 12, 2022 @07:04AM (#31352208)

Testing can’t prove the absence of bugs.

[ Parent | on HN ]