4 ms·
as a python programmer, you cannot think this way. <s>one reason you cannot think this way is because the GIL is a CPython concept. if you program with this re
by munin 13y ago
as a python programmer, you cannot think this way.
<s>one reason you cannot think this way is because the GIL is a CPython concept. if you program with this restriction in mind, you're not writing python, you're writing python targeted to the CPython implementation of python.</s> - edit, this is actually wrong, a comment below explains why.
the other reason is because it is misunderstanding of how the GIL works. the GIL is acquired for each python instruction so no two instructions will race against each other in the interpreter. however, two threads could have any arbitrary ordering of instructions and there is not a strict correspondence of instructions to statements.
CPython uses native threads for python threads so if you make multiple threads, they will race against each other. please don't make any assumptions about how the interpreter and those threads will interact, and just use either locks with good judgement or a lock-free algorithm that is grounded in a very deep understanding of the languages memory model.
- samps 13y agoWhile I agree that it's generally not helpful to rely on implicit atomicity in any Python, the reality is that all the other Pythons have followed CPython's lead and implemented the same memory model for compatibility. PyPy, Jython, and IronPython all have atomic bytecodes. So, for better or for worse, this bytecode atomicity is a de facto part of the language.
- munin 13y agooh! that makes sense. hooray. I'd strikethrough edit my post but I don't know how to make strikethrough markup :(
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]