With python3.5, fnmatch appears not to be thrad safe. It fails with the following exception:Traceback (most recent call last):  File "test.py", line 18, in <module>    f.result()  File "/opt/anaconda3/lib/python3.5/concurrent/futures/_base.py", line 405, in result    return self.__get_result()  File "/opt/anaconda3/lib/python3.5/concurrent/futures/_base.py", line 357, in __get_result    raise self._exception  File "/opt/anaconda3/lib/python3.5/concurrent/futures/thread.py", line 55, in run    result = self.fn(*self.args, **self.kwargs)  File "test.py", line 12, in foo    fnmatch(ref, s)  File "/opt/anaconda3/lib/python3.5/fnmatch.py", line 36, in fnmatch    return fnmatchcase(name, pat)  File "/opt/anaconda3/lib/python3.5/fnmatch.py", line 70, in fnmatchcase    match = _compile_pattern(pat)KeyError: ('SXJ8WZ9F7Z', <class 'str'>)Here is a minimal example reproducing the issue:import concurrent.futuresfrom fnmatch import fnmatchimport randomimport stringdef str_generator(size=10, chars=string.ascii_uppercase + string.digits):   return ''.join(random.choice(chars) for _ in range(size))def foo(strs, ref):    for s in strs:        fnmatch(ref, s)some_strings = [str_generator() for _ in range(500)]with concurrent.futures.ThreadPoolExecutor() as executor:    futures = [executor.submit(foo, some_strings, some_strings[0]) for _ in range(8)]    for f in futures:        f.result()$ python3 --versionPython 3.5.2 :: Anaconda 4.2.0 (64-bit)

Here's another way to reproduce the error. The problem seems to be in the C implementation of _lru_cache_wrapper() / bounded_lru_cache_wrapper().$ cat test.pyimport functoolsimport threadingimport time@functools.lru_cache(maxsize=2)def f(v):    time.sleep(.01)threads = [threading.Thread(target=f, args=(v,)) for v in [1,2,2,3,2]]for t in threads:    t.start()$ ./python test.pyException in thread Thread-5:Traceback (most recent call last):  File "/somewhere/Lib/threading.py", line 916, in _bootstrap_inner    self.run()  File "/somewhere/Lib/threading.py", line 864, in run    self._target(*self._args, **self._kwargs)KeyError: (2,)$ ./pythonPython 3.7.0a0 (default:654ec6ed3225+, Dec 15 2016, 11:24:30) [GCC 4.8.4] on linux

Thank you for your example Peter.Proposed patch fixes the KeyError. It introduces new private C API _PyDict_Pop_KnownHash(). It is like _PyDict_Pop(), but with precomputed hash.

Ned, can this be considered for inclusion in Python 3.6?   ISTM that this problematic in that it may already be causing hard-to-diagnose bugs in existing applications.

Before it could be considered for 3.6.0, it needs to be reviewed, pushed to the 3.6 branch for 3.6.1, and have some buildbot exposure.  3.6.0rc2 is in the process of manufacturing already.  Since this is a fairly extensive change, I think it would not be appropriate to throw it into a final release without prior release exposure.  Since it's also a bug in 3.5 and not a 3.6 release regression, I think it should wait for 3.6.1 unless we have a compelling reason to do a 3.6.0rc3.

An alternative patch changes semantic of _PyDict_Pop() with deflt == NULL, but makes the code simpler.

What solution do you prefer Raymond?

Antoine noticed that the first patch doesn't need special sentinel object. Thus it can be simplified.

With Antoine's suggestion lru_cache-dict-pop-simpler-3.5.patch no longer has an advantage. Just ignore it.

LGTM

Thanks Inada.Committed in9314aebc9674,5724c3ddf25b and9c852878a998. There were errors during pushing:remote: adding changesetsremote: adding manifestsremote: adding file changesremote: added 9 changesets with 15 changes to 5 filesremote: buildbot: change(s) sent successfullyremote: Traceback (most recent call last):remote:   File "/srv/hg/repos/hooks/hgroundup.py", line 56, in update_issueremote:     _update_issue(*args, **kwargs)remote:   File "/srv/hg/repos/hooks/hgroundup.py", line 108, in _update_issueremote:     s.login(username, password)remote:   File "/usr/lib/python2.7/smtplib.py", line 610, in loginremote:     AUTH_PLAIN + " " + encode_plain(user, password))remote:   File "/usr/lib/python2.7/smtplib.py", line 394, in docmdremote:     return self.getreply()remote:   File "/usr/lib/python2.7/smtplib.py", line 365, in getreplyremote:     + str(e))remote: SMTPServerDisconnected: Connection unexpectedly closed: timed outremote: error: changegroup.roundup hook raised an exception: Connection unexpectedly closed: timed outremote: notifiedpython-checkins@python.org of incoming changeset9314aebc9674remote: Traceback (most recent call last):remote:   File "/srv/hg/repos/hooks/mail.py", line 166, in incomingremote:     return _incoming(ui, repo, **kwargs)remote:   File "/srv/hg/repos/hooks/mail.py", line 157, in _incomingremote:     send(smtp, subj, sender, to, '\n'.join(body) + '\n')remote:   File "/srv/hg/repos/hooks/mail.py", line 37, in sendremote:     smtp.sendmail(sender, to, msg.as_string())remote:   File "/usr/lib/python2.7/smtplib.py", line 748, in sendmailremote:     (code, resp) = self.data(msg)remote:   File "/usr/lib/python2.7/smtplib.py", line 511, in dataremote:     (code, msg) = self.getreply()remote:   File "/usr/lib/python2.7/smtplib.py", line 365, in getreplyremote:     + str(e))remote: SMTPServerDisconnected: Connection unexpectedly closed: timed outremote: error: incoming.notify hook raised an exception: Connection unexpectedly closed: timed out...