[Python-Dev] [RFC] Removing pure Python implementation of OrderedDict (original) (raw)

INADA Naoki songofacandy at gmail.com
Tue Sep 5 22:26:52 EDT 2017

For example, when one thread do od[k1] = v1 and another thread do od[k2] = v2, result should be equivalent to one of od[k1] = v1; od[k2] = v2; or od[k2] = v2; od[k1] = v1. And internal data structure should be consistent. I agree the pure Python OrderedDict is not thread-safe. But who said it should?

No one. I meant just let's say "it should" from Python 3.7.

And, actually, are you sure the C implementation is? GIL switches can happen at many points. A simple PyDECREF, or perhaps even a tuple allocation can trigger a GC run that may release the GIL at some point in a finalizer function.

I know such difficulity already. I thought simple (when key is str or int) setitem doesn't break internal state of current C implementation of OrderedDict. And I'll carefully review my code too.

Sometime, writing reentrant and threadsafe container in C is easier than in Pure Python. The C and Python versions needn't make exactly the same guarantees.

Yes, of course. But what we can recommend for library developers (including stdlib)?

Currently, dict ordering is implementation detail of CPython and PyPy. We don't recommend to rely on the behavior.

Like that, should we say "atomic & threadsafe setitem for simple key is implementation detail of CPython and PyPy. We recommend using mutex when using OrderedDict from multiple thread."?

That was my point about thread safety.

Regards,

INADA Naoki <songofacandy at gmail.com>

More information about the Python-Dev mailing list