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

Antoine Pitrou solipsis at pitrou.net
Tue Sep 5 15:20:24 EDT 2017

On Wed, 6 Sep 2017 03:20:43 +0900 INADA Naoki <songofacandy at gmail.com> wrote:

What is idiomatic? For example, in this test case:

https://github.com/python/cpython/blob/564a2c68add64ebf2e558a54f5697513b19293cb/Lib/test/testordereddict.py#L575-L582 def testdictdelitem(self): OrderedDict = self.OrderedDict od = OrderedDict() od['spam'] = 1 od['ham'] = 2 dict.delitem(od, 'spam') with self.assertRaises(KeyError): repr(od) Since dict.delitem is same to OrderedDict.delitem in PyPy implementation, repr(od) doesn't raise KeyError.

Since this test is testing an implementation detail, it can safely be moved to a test class specific to the pure Python implementation.

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? 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.

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.

Regards

Antoine.

More information about the Python-Dev mailing list