Python complaints

[James Logajan]

Fredrik Lundh wrote:
> 
> James Logajan <JamesL at Lugoj.Com> wrote:
> > Sorry, but I think the price paid for "true" GC is too high for the small
> > number of programs that benefit from this. Perhaps one should learn to clean
> > up after oneself when cycles are expected.
> 
> Hmm.  I've recently dissected two large (and very complicated)
> Python projects, and one of the major cost contributors when
> going from "working code" to "production quality code" was the
> time needed to hunt down a number of totally unexpected re-
> source leaks.  GC would have helped in most of those cases.
> 
> (and in contrast what people claim on this list, more
> syntactic sugar or static typing would have saved al-
> most nothing...)
> 
> I plan to write a longer piece on this at a later time.

But you were able to track those resource leaks down. And correct them
because the language was designed with enough flexibility to aid in a
solution, not designed with a perhaps inappropriate and unchangeable
a-priori solution. Consider:

I've worked on two projects where deterministic memory management was an
implied requirement. One was a field-programmable embedded device for use in
remote network monitoring (actually, see
http://www.badger.com/html/main/products/oremote.html although this doesn't
give a lot of information on the software). Java was considered and dropped
for several reasons. Its non-deterministic GC didn't help its case at all.
If Python had had non-deterministic GC behavior, we might not have chosen it
either. Since it is programmable, it is possible for technicians to write
Python code with memory leaks. But memory leaks in application scripts can
be found and fixed and memory recovered at known points in processing.
However, a GC algorithm built into a language that is inappropriate for a
given application allows for no fixing...ever.

The other project is a telecommunications device for a startup firm where I
work now. Java and C++ were both considered as possible tools for the bulk
of development. Most developers on the team were in favor of Java because
newer compilers and VMs were closing the speed gap with C++ and Java's
memory management would have sped up development. Alas, after discussing our
requirements with Sun Java experts we came away with two important
conclusions:

1) Amazingly, Sun couldn't guarantee that their Java VM didn't have leaks!
2) They strongly recommended against using Java in any mission-critical
applications where non-deterministic GC behavior would be detrimental to the
application users (i.e. sudden execution pauses while the VM did a
mark-and-sweep collection).

We do use Java some, but only outside the core application which is written
in C++.

I suppose any solution for Python that allows some flexibility in the matter
would be nice. Perhaps keep the reference counting and add interpreter flags
to allow a choice of other GC schemes on top of that to clean up cycles.

Just my 2 cents....