3 ms·
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 t
by colordrops 3y ago
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.
- lisper 3y agoSure, 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.
- colordrops 3y agoWhat's the rationale? Making it opt-in avoids breaking legacy code, which is a huge advantage. What's the caae making it opt-out?
- lisper 3y agoWhy are you asking me to defend a position that I have explicitly disclaimed?
- deleted 3y ago[deleted]
- colordrops 3y agoNo, 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.
- lisper 3y agoDo you see where I wrote, "Sure, whatever." upstream? What do you think that means?
- colordrops 3y agoI saw the "indeed should not be", which seems to even more strongly indicate the opposite.
- lisper 3y agoYou 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.