Python's biggest compromises

[Hannu Kankaanpää]

Michael Hudson <mwh at python.net> wrote in message news:<7h3brv9a9oz.fsf at pc150.maths.bris.ac.uk>...
> <button nature="hot">
> Reference counting *is* a form of garbage collection.
> </button>

You apparently have such a loose definition for garbage
collection, that even C programs have "a form of garbage
collection" on modern OSes: All garbage is reclaimed by
the OS when the program exits. It's just a very lazy collector.

I don't consider something a garbage collector unless it
collects all garbage (ref.counting doesn't) and is a bit more
agile than the one provided by OS.

> Saying "Ref. counting sucks, let's use GC instead" is a statement near
> as dammit to meaningless.

You, I and everyone knows what I was talking about, so it could
hardly be regarded as "meaningless".

> Given the desires above, I really cannot think of a clearly better GC
> strategy for Python that the one currently employed.  AFAICS, the
> current scheme's biggest drawback is its memory overhead, followed by
> the cache-trashing tendencies of decrefs.

It's not "the one currently employed". It's the *two* currently
employed and that causes grief as I described in my previous post.
And AFAIK, Ruby does use GC (mark-and-sweep, if you wish) and
seems to be working. However, this is rather iffy knowledge. I'm
actually longing for real GC because I've seen it work well in
Java and C#, and I know that it's being used successfully in many
other languages.

> What would you use instead?

A trick question?