[Python-Dev] [RFC] Removing pure Python implementation of OrderedDict (original) (raw)
Paul Moore p.f.moore at gmail.com
Wed Sep 6 06:40:33 EDT 2017
- Previous message (by thread): [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict
- Next message (by thread): [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict
- Next message (by thread): [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]