Python 2.0

[Tim Peters]

[Paul Prescod]
> But I think that the bigger problem with "real GC" is that C programs
> often hang on to references to Python objects and any kind of compacting
> GC would invalidate those references.

[Yukihiro Matsumoto]
> It's the common legend especially here in comp.lang.python.
>
> From my experience with Scheme and Ruby, both with real GC, the real
> GC is mostly very fast.  Fast enough no one notices its "hang" on most
> cases.  The legend was formed up by old GC implementation and slower
> machines of the past, I guess.

Matz, this one is just a misunderstanding.  Paul's "hang" doesn't refer to
time.  It's more like "retain", as in "keep a pointer to".  "compacting" is
the key there:  compacting GC (one that relocates live objects) creates
problems for C extensions that have saved away ("hung on to") the addresses
of objects.  But GC doesn't have to be compacting in order to reclaim
cycles; Paul is likely reacting to the "self-contained universe"
inter-language hostility common among languages with compacting GC (like
Icon or Java).

betting-a-nickel-python2-won't-compact-ly y'rs  - tim