[Python-Dev] gc ideas -- sparse memory (original) (raw)
Maciej Fijalkowski fijall at gmail.com
Sat Dec 4 14:01:47 CET 2010
- Previous message: [Python-Dev] gc ideas -- sparse memory
- Next message: [Python-Dev] gc ideas -- sparse memory
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Dec 4, 2010 at 1:37 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
On Sat, 4 Dec 2010 15:06:45 +1100 Cameron Simpson <cs at zip.com.au> wrote:
On 03Dec2010 18:15, James Y Knight <foom at fuhm.net> wrote: | On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote: | > gc is implementation specific. CPython uses ref counting + cycle | > gc. A constraint on all implementations is that objects have a fixed, | > unique id during their lifetime. CPython uses the address as the id, so | > it cannot move objects. Other implementations do differently. Compacting | > gc requires an id to current address table or something. | | It's somewhat unfortuante that python has this constraint, instead of | the looser: "objects have a fixed id during their lifetime", which is | much easier to implement, and practically as useful.
Python doesn't have the constraint you imagine; it does have "objects have a fixed id during their lifetime". CPython has this constraint because it uses the address as the id, which is free and needs no papping or extra storage. Well, the main reason CPython has this constraint is that the C API mandates constant object pointers. That we can then reuse the pointer for id() is only a consequence of this. Regards Antoine.
Yes.
I think further discussion of Java-vs-Python makes no sense (and it's proven that C-API-less python can exist and be compatible)
- Previous message: [Python-Dev] gc ideas -- sparse memory
- Next message: [Python-Dev] gc ideas -- sparse memory
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]