[Python-Dev] Issue 10194 - Adding a gc.remap() function

[Peter Ingebretson]

--- On Tue, 10/26/10, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> I think this then mandates a PEP; I'm -1 on the feature also. 
>> 
>> I am happy to write up a PEP for this feature.  I'll start that 
>> process now, though if anyone feels that this idea has no chance of 
>> acceptance please let me know.
> 
> If it could actually work in a reasonable way, I would be +0. If,
> as I think, it can't possibly work correctly, I'll be -1.
> 
> In this evaluation, I compare this to Smalltalk's
> Object>>#become:
> What you propose should have a similar effect, IMO, although
> it's probably not necessary to provide the two-way nature
> of become.

Thanks, I didn't know about Object>>#become until now but it 
is a perfect comparison.  The two-way nature of become appears to 
be due to the implementation detail of swapping two entries in a 
table, but the current spec for gc.remap can achieve the same effect
with:
>>> gc.remap({a:b, b:a})

Of course #become and gc.remap also share the same power and danger.

I'm retracting the patch in 10194 and will submit a new one later 
as part of the PEP that uses a parallel traverse mechanism.  Still, 
if you are concerned that this approach cannot work I encourage you 
to try out the patch associated with 10194 by playing around with 
gc.remap in the interpreter or looking at the unit tests.  I was 
surprised when I made the change initially by how little code was 
required and by how well it seemed to work in practice.

Thanks,
Peter