[Python-Dev] Python 2.3a1's mandatory use of cyclic GC causes existing applications to fail

[Tim Peters]

[Michael Hudson]
> I'm not fully aware of all the issues, but I think that the
> interaction between the sometimes-there-sometimes-not gc code and the
> trashcan facility for safely deallocating deeply nested structures was
> deeply confusing and was a motivation for making the GC code
> non-optional.

That's so, and the trashcan code was the source of critical bugs.  The
trashcan code is nearly obvious when we can rely on gc being there, and
extension modules can easily use the trashcan machinery too.  In the absence
of cyclic gc, extension modules can't use the trashcan machinery without
editing the core Python source code to teach the trashcan about each type
that wants to participate, and the trashcan implementation was much harder
to get right (it took us years to get to the state where we thought it might
finally be right <wink>).

> So desirable or not, re-adding --without-cycle-gc may be *hard*.

It would be, yes.  Note too that --without-cycle-gc was never intended to be
an ongoing config option.  It was a hairy experimental feature at first, and
we wanted a way to back it out quickly if the design proved to have fatal
flaws.  That didn't happen.