Both of the former provide stronger promises about how likely changes in the future are. For the former, user input and coordination is absolutely required. Im

Both of the former provide stronger promises about how likely changes in the future are. For the former, user input and coordination is absolutely required. Implementation details are documented to allow performance optimizations and to give insight into why certain things are how they are. Therefore, users can reasonably expect that the vendor won't cause performance regressions for existing code. However, it is unwise to derive semantics from them, even if they are technically documented in that way. One of the biggest disadvantages of relying on implementation details is that it makes it way more troublesome for the vendor to maintain and improve the product. Anyways, the GIL and the presence of possible concurrency bugs are completely orthogonal things as the GIL has always only served to prevent corruption of runtime data structures, not of user code.