May I ask how acquainted you ar with parallel code, including multi-threading, in Python?

Because as far as I can perceive none of the types or operations you mention have
any race conditions in multi-threaded Python code, and for multi-process or async code that
is not a problem by design but for data designed to be shared, like memory mapped
stuff (and then locks are the only way to go anyway).

Primitive data types like numbers and strings are imutable to startwith, so it
is "very impossible" for multi-threading code to be an issue when using then. 
As for composite native data types like dicts, lists and sets, that could theoretically be left in an 
inconsistent state, that is already taken care of by the GIL. And even for user designed types,
it is a matter of adding a threading lock inside the proper dunder methods, and it
also fixes the issue for the users of those types. 

The only time I had to worry about a lock in a data type in Python (i.e., not a  
program wide state that is inherent to my problem), was when asking a novice question on
"how to rename a dict key" - and even them, it felt a bit overkill.

In other words, I may be wrong, but I think you are talking about a non-issue here.

On Sun, 8 Sep 2019 at 11:33, Vinay Sharma via Python-ideas <> wrote:
Currently, C++ has support for atomic types, on which operations like add, sub, xor, etc can be done atomically, thereby avoiding data races.
Having such a support will be very helpful in Python.

For instance users won't have to use Locks for synchronising shared variables in case of multiprocessing. And, directly passing these atomic objects would be enough. These objects can have methods such as add, sub, etc to change the underlying variable.

I believe this would make python much more easier for users in both trivial and complicated cases, without having to use lock.

gcc also provides inbuilt support for some atomic operations. Documentation for the same is available at

Moreover, gcc also has support for Memory Model aware atomic operations documented at
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: