[Python-Dev] Issue 10194 - Adding a gc.remap() function (original) (raw)
Peter Ingebretson pingebre at yahoo.com
Tue Oct 26 23:45:10 CEST 2010
- Previous message: [Python-Dev] Issue 10194 - Adding a gc.remap() function
- Next message: [Python-Dev] Issue 10194 - Adding a gc.remap() function
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--- 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
- Previous message: [Python-Dev] Issue 10194 - Adding a gc.remap() function
- Next message: [Python-Dev] Issue 10194 - Adding a gc.remap() function
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]