> There was also a large amount of concern from the attendees about the impact the introduction of nogil could have on CPython development. Some worried that introducing nogil mode could mean that the number of tests run in CI would have to double. Others worried that the maintenance burden would significantly increase if two separate versions of CPython were supported simultaneously: one with the GIL, and one without.
This seems like a key consideration for the long-term success of nogil and CPython. The Python ecosystem has survived and recovered from past forks but it would good to avoid forks altogether if possible, especially if nogil proves to be stable and performant enough for prime time. At the least we should try to keep any forks short-term, e.g. starting with a compiler flag with a timeline for shifting to a runtime flag. (These are just my thoughts, take everything with a pinch of salt.)
This would totally make sense. A major change in architecture with some libraries breaking. While many people are still store from the 2->3 transition I would not expect this change to be that severe Most code should work for python 3 and 4 without changes.
This seems like a key consideration for the long-term success of nogil and CPython. The Python ecosystem has survived and recovered from past forks but it would good to avoid forks altogether if possible, especially if nogil proves to be stable and performant enough for prime time. At the least we should try to keep any forks short-term, e.g. starting with a compiler flag with a timeline for shifting to a runtime flag. (These are just my thoughts, take everything with a pinch of salt.)