4 ms·

I’ve seen no description of how this won’t be like 2 -> 3 except: 1. We don’t want it to be. 2. We’ll give up quickly if it is. Those are both important poin

I’ve seen no description of how this won’t be like 2 -> 3 except: 1. We don’t want it to be. 2. We’ll give up quickly if it is. Those are both important points. But there seems to be an important missing third piece of “and we’ll achieve this by…”.

miraculixx 3y ago
Indeed. Also once that Genie is out putting it back will be next to impossible.
n2d4 3y ago
Quoting my comment from elsewhere: >I didn't dive deep on this, but I assume that GIL mode can still run anything, including no-GIL code (it is one of their promises, at least). So, unlike 2->3, there is forwards-compatibility. >It also seems like the latter isn't meant as a replacement (for the moment), but rather as an option. As long as GIL mode remains compatible with both old and new code, I see very little danger in having a no-GIL mode (besides hogging CPython maintainers' time).
- travisjungroth 3y ago
  I under-appreciated the forward comparability. So this partly a framing critique. If you’re going to frame it as “how this won’t be like before”, good to really highlight the how.
qbasic_forever 3y ago
Agreed--there needs to be discussion and thought about how this impacts library maintainers. How do they tell users their library supports or doesn't support non-GIL mode? Will pypi have new metadata to specify and enforce projectsdependencies support non-GIL mode, or is it just a chaotic free for all where users have to figure that out themselves? How will a library author have one codebase that supports both GIL and non-GIL mode--will they effectively fork the code and maintain two codebases (yuck!) or will there be support for detecting GIL mode? How does this work for C extensions too? There's a ton of work to make this smooth for libraries and I really hope it is being thought through better than the python 2 to 3 story for library authors (which was no story and chaos).
slt2021 3y ago
quite a large set of users are using default python installation. There is large number of companies and non-trivial codebases that run on default python that comes with the oldest LTS version of Linux distro. currently quite a lot of companies use python3.6 only because it comes standard with the Ubuntu 14.04.6 which happens to be the oldest LTS version - and companies have habit of migrating from out-of-support LTS version to currently-supported-oldest-LTS this can repeat 2->3 because there will be users stuck with older versions of python and library maintainers will have to maintain both versions: with GIL and without GIL (just like PHP extension developers did with thread safe methods)
- vlz 3y ago
  But shouldn't old GIL python versions be fine running code that is no-GIL compatible (assuming it is otherwise compatible)? Having a thread per process doesn't mean you cannot run code which is fine with having n threads per process. So if you maintain code which is otherwise compatible with e.g. python 3.6, after making it no-GIL compatible it should still be compatible to 3.6.

miraculixx 3y ago

Indeed. Also once that Genie is out putting it back will be next to impossible.

n2d4 3y ago

Quoting my comment from elsewhere: >I didn't dive deep on this, but I assume that GIL mode can still run anything, including no-GIL code (it is one of their promises, at least). So, unlike 2->3, there is forwards-compatibility. >It also seems like the latter isn't meant as a replacement (for the moment), but rather as an option. As long as GIL mode remains compatible with both old and new code, I see very little danger in having a no-GIL mode (besides hogging CPython maintainers' time).

travisjungroth 3y ago
I under-appreciated the forward comparability. So this partly a framing critique. If you’re going to frame it as “how this won’t be like before”, good to really highlight the how.

qbasic_forever 3y ago

Agreed--there needs to be discussion and thought about how this impacts library maintainers. How do they tell users their library supports or doesn't support non-GIL mode? Will pypi have new metadata to specify and enforce projectsdependencies support non-GIL mode, or is it just a chaotic free for all where users have to figure that out themselves? How will a library author have one codebase that supports both GIL and non-GIL mode--will they effectively fork the code and maintain two codebases (yuck!) or will there be support for detecting GIL mode? How does this work for C extensions too? There's a ton of work to make this smooth for libraries and I really hope it is being thought through better than the python 2 to 3 story for library authors (which was no story and chaos).

slt2021 3y ago

quite a large set of users are using default python installation. There is large number of companies and non-trivial codebases that run on default python that comes with the oldest LTS version of Linux distro. currently quite a lot of companies use python3.6 only because it comes standard with the Ubuntu 14.04.6 which happens to be the oldest LTS version - and companies have habit of migrating from out-of-support LTS version to currently-supported-oldest-LTS this can repeat 2->3 because there will be users stuck with older versions of python and library maintainers will have to maintain both versions: with GIL and without GIL (just like PHP extension developers did with thread safe methods)

vlz 3y ago
But shouldn't old GIL python versions be fine running code that is no-GIL compatible (assuming it is otherwise compatible)? Having a thread per process doesn't mean you cannot run code which is fine with having n threads per process. So if you maintain code which is otherwise compatible with e.g. python 3.6, after making it no-GIL compatible it should still be compatible to 3.6.