homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients docs@python, eric.snow, eryksun, ethan.furman, paul.moore, rhettinger
Date 2015年04月21日.19:11:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429643501.58.0.53381308846.issue24020@psf.upfronthosting.co.za>
In-reply-to
Content
FYI, I've used thread-local namespaces with success in several different ways and none of them involved binding the thread-local namespace to global scope. I don't think anything needs to be fixed here.
The SO answer is misleading and perhaps even wrong. The problem it describes is about sharing the thread-local NS *between function calls*. Persisting state between function calls is not a new or mysterious problem, nor unique to thread-local namespaces. In the example they give, rather than a global they could have put it into a default arg or into a class:
def hi(threadlocal=threading.local()):
 ...
class Hi:
 threadlocal = threading.local()
 def __call__(self):
 ... # change threadlocal to self.threadlocal
hi = Hi()
This is simply a consequence of Python's normal scoping rules (should be unsurprising) and the fact that threading.local is a class (new instance per call) rather than a function (with the assumption of a singleton namespace per thread).
At most the docs could be a little more clear that threading.local() produces a new namespace each time. However, I don't think even that is necessary and suggest closing this as won't fix.
History
Date User Action Args
2015年04月21日 19:11:41eric.snowsetrecipients: + eric.snow, rhettinger, paul.moore, docs@python, ethan.furman, eryksun
2015年04月21日 19:11:41eric.snowsetmessageid: <1429643501.58.0.53381308846.issue24020@psf.upfronthosting.co.za>
2015年04月21日 19:11:41eric.snowlinkissue24020 messages
2015年04月21日 19:11:41eric.snowcreate

AltStyle によって変換されたページ (->オリジナル) /