[Python-ideas] make __closure__ writable

[Eric Snow]

On Tue, Mar 20, 2012 at 7:31 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2012-03-20, at 9:15 AM, Nick Coghlan wrote:
>
>> On Tue, Mar 20, 2012 at 11:06 PM, Yury Selivanov
>> <yselivanov.ml at gmail.com> 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.

-0 (for now :)

"it won't break anything" isn't the only metric that should be
considered here.  Would this change make it too easy for people to
write hard-to-debug code without realizing it?  Would this create an
attractive nuisance?  I don't have enough Guido-fu to answer these
questions.

Though __code__ is already writable, I don't think it's a good
comparison about which to reason.  The object bound to __code__ is
much more complex (and guarded) than the one bound to __closure__.  I
expect that it would be much easier to do the wrong thing with
__closure__.  As well, it seems to me that hacking  __closure__ would
be much more tempting.

Will we see a "significantly" higher number of bugs about segfaults
where we have to respond with "don't do that"?  Probably not.  But
should any solution here guard (at some expense) against such mistakes
that currently are much more difficult to make?  Nick already alluded
to double-checking the code somewhat to that effect.

I'm not opposed in principle to making __closure__ writable, but worry
that not all the angles are being considered here.

-eric