3 ms·
I think you're right. Making it an explicit opt-out, as is planned for the first stage, should be fine. Expecting to make it opt-in in 5 years seems too optimis
by tgv 3y ago
I think you're right. Making it an explicit opt-out, as is planned for the first stage, should be fine. Expecting to make it opt-in in 5 years seems too optimistic to me. It relies on all the library developers to fix their libraries (also the Python ones). That's tough work, and importantly, if done well, it will even go unappreciated: nobody will notice it.
Many libraries have never had a multi-processing use case, others are so big that bugs are bound to happen, many of them subtle, so one guaranteed outcome will be unreproducible complaints and devs throwing in the towel. Opt-in will make people unhappy.
- Arbortheus 3y agoSurely if it goes well people will see their existing python codebases become more performant with no development required aside from updating some dependencies? Not nobody will notice it. It seems like it could be a great outcome for developers.
- tgv 3y agoSo, removing the GIL will slow down Python, at least initially. Speed gains from multi-threading won't come if you don't change your code, unless you happen to use a library that becomes multi-threaded (in which case you have to start worrying about callbacks). > It seems like it could be a great outcome for developers. For the ones that use certain libraries, not for those that have to build them.