3 ms·

It's absolutely pertinent to this discussion, this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is

by Kranar 3y ago

It's absolutely pertinent to this discussion, this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. Others object saying that the Python reference document is what specifies its semantics, not the reference implementation. My position is that both the CPython reference implementation and the reference documentation are valid sources that document Python's semantics and that they both can and should be used.

samus 3y ago
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.
pdonis 3y ago
> this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. And my position is that it is not because there are other implementations of Python that do not have it, and which everybody agrees are implementations of Python. Not only that, but the very language reference that I linked to explicitly distinguishes CPython implementation details from the language itself. So the Python dev team does not appear to agree with your position.

by Kranar 3y ago

samus 3y ago

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.

pdonis 3y ago

> this whole discussion is about whether the GIL is part of the semantics of a Python program or not. My position is that it is because the GIL is a part of the CPython reference implementation. And my position is that it is not because there are other implementations of Python that do not have it, and which everybody agrees are implementations of Python. Not only that, but the very language reference that I linked to explicitly distinguishes CPython implementation details from the language itself. So the Python dev team does not appear to agree with your position.