Python's biggest compromises

[John Roth]

"Hannu Kankaanpää" <hanzspam at yahoo.com.au> wrote in message
news:840592e1.0307312304.77a0a05f at posting.google.com...
> anthony_barker at hotmail.com (Anthony_Barker) wrote in message
news:<899f842.0307310555.56134f71 at posting.google.com>...
> > What to you think python largest compromises are?
>
> I think reference counting is. Added to this the fact that
> garbage collection is also possible (as in Jython). So we get
> the worst of both worlds.
>
> 1. Idioms like this won't work portably:
>
> def foo():
>    f = file('x')
>    return f.read()
>
> Even though f.__del__ closes the file, in garbage
> collected environment the f object might not get deleted
> in a good while, and would cause problems.
>
> 2. And then, we still need to use weakref to ensure
> that our crossreferenced stuff works both with and without GC.
>
> Worst of both indeed. Maybe the decision to choose reference
> counting was driven by speed considerations. That might've
> been reasonable back in early 90's, but GC techniques have
> evolved from those days and so GC would be a superior
> technique now.
>
> Well, since no one else pointed this out yet, maybe there's
> some flaw in my reasoning.

There's a flaw in your reasoning. The various techniques that
descend from mark and sweep (which is what you're
calling garbage collection) depend on being able to
identify all of the objects pointed to. For objects that are
owned by Python, that's a lengthy (that is, inefficient)
process, and it's not possible in general for objects that
are created by extensions.

Reference counting only depends on having the
object itself, and control of the creation and removal
of references. The latter is a frequent source of bugs
and memory leaks in extensions.

It's easy to say that various languages would be improved
by adding "real" garbage collection, but those techniques
impose significant design constraints on the implementation
model.

John Roth