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 ncoghlan
Recipients Mark.Shannon, arigo, belopolsky, benjamin.peterson, ncoghlan, njs, xgdomingo, yselivanov
Date 2017-06-24.13:31:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1498311108.52.0.4906499906.issue30744@psf.upfronthosting.co.za>
In-reply-to
Content
The writeback-only-if-changed approach sounds like a plausible improvement to me. I'd be hesitant to include such a change in 3.5.4 though, since we don't get a second go at that if something breaks unexpectedly.

However, I don't think returning a write-through proxy from locals() would be a good idea, since you can still have race conditions between "read-update-writeback" operations that affect the cells directly, as well as with those that use the new write-through proxy. At the moment, you can only get yourself into trouble by way of operations that have access to LocalsToFast, and those are pretty rare now that `exec` is no longer a statement.

If folks really want that write-through behaviour (at least for closure variables), 3.7 will let them write it themselves, since closure cells are becoming writeable from pure Python code:

>>> def outer():
...     x = 1
...     def inner():
...         return x
...     return inner
... 
>>> f = outer()
>>> f.__closure__[0].cell_contents
1
>>> f.__closure__[0].cell_contents = 2
>>> f()
2
>>> f.__closure__[0].cell_contents = "hello"
>>> f()
'hello'
```
History
Date User Action Args
2017-06-24 13:31:48ncoghlansetrecipients: + ncoghlan, arigo, belopolsky, benjamin.peterson, njs, Mark.Shannon, yselivanov, xgdomingo
2017-06-24 13:31:48ncoghlansetmessageid: <1498311108.52.0.4906499906.issue30744@psf.upfronthosting.co.za>
2017-06-24 13:31:48ncoghlanlinkissue30744 messages
2017-06-24 13:31:47ncoghlancreate