Re:No-GIL mode coming for Python
by ctoth on Friday July 28, 2023 @11:27PM
(#36916564)
Except they're not at all analogous situations.
In python 2 -> 3, if a new version of a library came out Python 3 only, you couldn't use both it, and your old Python 2 code at the same time.
Here, you can use the GIL until every one of your dependencies have migrated, even as new versions of your dependencies come out with nogil support until one magical day they all have nogil and you can migrate. But since you have been able to keep up with the library and weren't just arbitrarily cut off at their last Python2/GIL version, it's not a huge breaking change!
[ Parent
| on HN ]
Re:No-GIL mode coming for Python
by miraculixx on Saturday July 29, 2023 @02:27AM
(#36917485)
I think this is misreading the PEP, but I am happy to learn otherwise.
If it was like you say there would be no need for the --nogil cli option. And there would be no need to have a discussion, at all, really. Python could just introduce the featuere and enable or disable the gil based on the packages installed and the highest threading mode possible.
Yet that is not what's planned as I read it.
Re:No-GIL mode coming for Python
by usrbinbash on Saturday July 29, 2023 @03:27AM
(#36917789)
> If it was like you say there would be no need for the --nogil cli option.
Testing the difference between running it with and without `nogil` without having to install 2 different interpreters.
Testing libraries during transitions.
Simply giving users a choice.
Convenience.
Almost no one uses pre-Go.1.11 (GOPATH instead of Modules) any more for project organisation, and the transition is trivially easy. And yet, the toolchain still reacts to `GO111MODULE=off`.