5 ms·

I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle. They’ll have to be intensely careful not to accidentally affect yes-G

I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle. They’ll have to be intensely careful not to accidentally affect yes-GIL behaviour. All kinds of weird cases are possible if any sort of emulated GIL isn’t exactly like with a GIL.

miraculixx 3y ago
I am sure the intent is good. I am not so sure it is possible to avoid. They already say it could take 5+ years of having gil + nogil exist in parallel. For any tool builder that means their cost has just doubled for the next five years, at least. Why? Because people will want to use tools in either mode, no matter if it is deemed productive or experimental.
- slt2021 3y ago
  essentially the adoption of No-GIL Python will depend on: 1. In which version No-GIL will become default option in CPython 2. When that CPython version will come standard in LTS Linux distro 3. When all earlier LTS distros will go out of support 4. When companies switch from outdated to target LTS version of 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
  - pmontra 3y ago
    A customer on 18.04 just told me to wait another year and migrate their servers to 24.04 so they can stay there until 2029, or will that be 2030? They are on the standard 5 years LTS support, not the extended 10 years one.
travisjungroth 3y ago
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)

miraculixx 3y ago

I am sure the intent is good. I am not so sure it is possible to avoid. They already say it could take 5+ years of having gil + nogil exist in parallel. For any tool builder that means their cost has just doubled for the next five years, at least. Why? Because people will want to use tools in either mode, no matter if it is deemed productive or experimental.

slt2021 3y ago
essentially the adoption of No-GIL Python will depend on: 1. In which version No-GIL will become default option in CPython 2. When that CPython version will come standard in LTS Linux distro 3. When all earlier LTS distros will go out of support 4. When companies switch from outdated to target LTS version of 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
- pmontra 3y ago
  A customer on 18.04 just told me to wait another year and migrate their servers to 24.04 so they can stay there until 2029, or will that be 2030? They are on the standard 5 years LTS support, not the extended 10 years one.

travisjungroth 3y ago

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)