[Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

[INADA Naoki]

>
>> 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 Py_DECREF, 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>