RetroSearch Browse

Tue Sep 5 15:20:24 EDT 2017 · http://mail.python.org/pipermail/python-dev/2017-September/149167.html

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/test_ordered_dict.py#L575-L582
> 
>     def test_dict_delitem(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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2017-September/149167.html below:

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