On 2012-03-20, at 9:15 AM, Nick Coghlan wrote:
On Tue, Mar 20, 2012 at 11:06 PM, Yury Selivanov
wrote: Again, since the __code__ attribute is modifiable, and __closure__ works in tight conjunction with it, I see no point in protecting it.
FWIW, I'm current +0 on the idea (based on Yury's reasoning here about updating already wrapped functions), but it's going to be a while before I can dig into the code and see if there are any *good* reasons we protect __closure__ (rather than that protection merely being an implementation artifact). I can't recall any off the top of my head, but that part of the code is complex enough that I don't completely trust my memory on that point.
Well, it seems that it is an implementation artifact. I've run across the CPython code, and got an impression that changing __closure__ to be writeable won't break anything. Writing malicious values to it may segfault python, but that's no different from doing so with __code__. In some way, __closure__ is already writeable, since you can pass it to the 'types.FunctionObject', and create a broken function, hence I don't see a reason in making it readonly. The patch attached to the issue in the tracker passes all unittests, and adds one more - specifically for testing __closure__ modification on a live function object. - Yury