3 ms·
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?
by colordrops 3y ago
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?
- 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.