https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1
On Wed, Sep 6, 2017 at 5:49 PM, INADA Naoki <songofaca...@gmail.com> wrote: > OK, I stop worring about thread safety and other implementation > detail behavior on edge cases. > > Thanks, > > INADA Naoki <songofaca...@gmail.com> > > > On Wed, Sep 6, 2017 at 7:40 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 6 September 2017 at 11:09, Antoine Pitrou <solip...@pitrou.net> wrote: >>> On Wed, 6 Sep 2017 11:26:52 +0900 >>> INADA Naoki <songofaca...@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@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/agoretoy%40gmail.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
