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 r.david.murray
Recipients amaury.forgeotdarc, bgailer, docs@python, eric.araujo, eric.snow, ethan.furman, flox, georg.brandl, martin.panter, ncoghlan, nedbat, r.david.murray, techtonik, terry.reedy
Date 2015-01-15.14:59:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1421333963.23.0.133175030007.issue17546@psf.upfronthosting.co.za>
In-reply-to
Content
Yeah, the question of thread-safety in regards to what we are talking about here also occurred to me.  That is, the wording makes one wonder if locals is thread safe or not.  I don't see your suggested wording as making it clearer, though.

The problem is that it *is* underspecified.

So I think the correct description of the current under-specification is that locals() returns a copy of the current locals namespace.  If you modify the thing returned by locals it may or may not update the local namespace.  If you modify the local namespace (by doing x = y or its equivalents) the change may or may not be reflected in the object that was returned by locals().

Now, how do we boil that down?  Or do we just say it more or less that way?
History
Date User Action Args
2015-01-15 14:59:23r.david.murraysetrecipients: + r.david.murray, georg.brandl, terry.reedy, amaury.forgeotdarc, ncoghlan, techtonik, nedbat, bgailer, eric.araujo, flox, docs@python, ethan.furman, eric.snow, martin.panter
2015-01-15 14:59:23r.david.murraysetmessageid: <1421333963.23.0.133175030007.issue17546@psf.upfronthosting.co.za>
2015-01-15 14:59:23r.david.murraylinkissue17546 messages
2015-01-15 14:59:22r.david.murraycreate