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.