Re:Progress on No-GIL CPython
by colordrops on Friday October 20, 2023 @06:18PM
(#37962124)
Wouldn't the most practical solution be for a script or module to turn it off instead? Then you don't break any legacy code. Anyone writing code that is meant to work without the GIL would know to turn it off.
[ Parent
| on HN ]
Sure, whatever. The point is that breaking legacy code doesn't have to be a show-stopper for eliminating the GIL, and backwards-compatibility does not have to be (indeed should not be) an overriding consideration in a GIL-free Python.
Re:Progress on No-GIL CPython
by colordrops on Friday October 20, 2023 @07:49PM
(#37962758)
What's the rationale? Making it opt-in avoids breaking legacy code, which is a huge advantage. What's the caae making it opt-out?
Why are you asking me to defend a position that I have explicitly disclaimed?
Re:Progress on No-GIL CPython
by colordrops on Saturday October 21, 2023 @12:20PM
(#37968130)
No, you claimed the opposite. You suggest that disabling the GIL should be opt-out (or conversely enabling the GIL should be opt-in). This means that many legacy packages will break by default. You said it should be this way. Why?
Don't downvote me, answer the question.
Do you see where I wrote, "Sure, whatever." upstream? What do you think that means?
Re:Progress on No-GIL CPython
by colordrops on Wednesday October 25, 2023 @01:23AM
(#38009427)
I saw the "indeed should not be", which seems to even more strongly indicate the opposite.
You seem to have some serious reading comprehension issues. The context of that phrase was this sentence:
"The point is that breaking legacy code doesn't have to be a show-stopper for eliminating the GIL, and backwards-compatibility does not have to be (indeed should not be) an overriding consideration in a GIL-free Python."
That has nothing to do with opt-in vs opt-out.