Nick Coghlan <ncogh...@gmail.com> added the comment: The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one.
This a case where the user may legitimately not realise that threading.local is stored in the *temporary* state created by ctypes rather than in something more persistent inside the interpreter. Since the ctypes state is per callback, it won't persist across calls, even when they're made from the same thread. Suggested wording: """Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation, including recreation of the thread local storage area. While this is correct for most purposes, it does mean that values stored with `threading.local` will *not* survive across different callbacks, even when those calls are made from the same C thread.""" ---------- keywords: +easy resolution: works for me -> stage: committed/rejected -> needs patch status: closed -> open type: behavior -> feature request _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6627> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
