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

INADA Naoki songofacandy at gmail.com
Wed Sep 6 06:49:56 EDT 2017

OK, I stop worring about thread safety and other implementation
detail behavior on edge cases.


INADA Naoki  <songofacandy at gmail.com>

On Wed, Sep 6, 2017 at 7:40 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 6 September 2017 at 11:09, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Wed, 6 Sep 2017 11:26:52 +0900
>> INADA Naoki <songofacandy at gmail.com> wrote:
>>> 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."?
>> I think you may be overstating the importance of making OrderedDict
>> thread-safe.  It's quite rare to be able to rely on the thread safety
>> of a single structure, since most often your state is more complex than
>> that and you have to use a lock anyway.
>> The statu quo is that only experts rely on the thread-safety of list
>> and dict, and they should be ready to reconsider if some day the
>> guarantees change.
> Agreed. I wasn't even aware that list and dict were guaranteed
> threadsafe (in the language reference). And even if they are, there's
> going to be a lot of provisos that mean in practice you need to know
> what you're doing to rely on that. Simple example:
>     mydict[the_value()] += 1
> isn't thread safe, no matter how thread safe dictionaries are.
> I don't have a strong opinion on making OrderedDict "guaranteed thread
> safe" according to the language definition. But I'm pretty certain
> that whether we do or not will make very little practical difference
> to the vast majority of Python users.
> Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com

More information about the Python-Dev mailing list