[Python-Dev] gc ideas -- sparse memory (original) (raw)

Maciej Fijalkowski fijall at gmail.com
Sat Dec 4 07:21:30 CET 2010

On Sat, Dec 4, 2010 at 6:34 AM, James Y Knight <foom at fuhm.net> wrote:

On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote:

On 12/3/2010 7:46 PM, James Y Knight wrote:

Sure they are. This is what Java provides you, for example. If you have fixed, but potentially non-unique ids (in Java you get this using "identityHashCode()"), you can still make an identity I do not see the point of calling a (non-unique) hash value the identity My point was simply that a) it's an unfortunate constraint on potential GC implementations that objects need to have a fixed and unique id in Python, and b) that it's not actually necessary to have such a constraint (in the abstract sense of required; obviously it's a requirement upon Python today, due to existing code which depends upon that promise). Would you be happier if I had said "it's unfortunate that Python has an "id" function instead of an "identityHashValue" function? I suppose that's what I really meant. Python the language would not have been harmed had it had from the start an identityHashValue() function instead of an id() function. In the CPython implementation, it may even have had the exact same behavior, but would've allowed other implementations more flexibility. James

I don't see how this related to moving vs non-moving GC. PyPy (and I believe IronPython and Java) all have fixed unique ids that are not necesarilly their addresses. The only problem is that id() computed that way is more costly performance-wise, but works.

More information about the Python-Dev mailing list