Queue cleanup

Paul Rubin no.email at nospam.invalid
Mon Aug 30 13:00:33 CEST 2010

Lawrence D'Oliveiro <ldo at geek-central.gen.new_zealand> writes:
>> If it hasn't happened to you yet, you're either burning a bunch of effort
>> that programmers of more automatic systems can put to more productive
>> uses ...
> What makes you say that? Avoiding bugs is not a “productive use”?

Avoiding any particular bug through constant and pervasive vigilance is
far less productive than using a system where causing that particular
type of bug is impossible to begin with.  IMO the code you posted has
latent bugs as discussed in the other post.  It might work at the moment
you checked it in but it is brittle.  I wouldn't have signed off on it
in a code review.

> And yet Java apps, for example, are (in)famous for excessive memory
> usage compared to those written in non-GC-dependent languages.

I think that may mostly be an issue with the bloated nature of most Java
apps.  Certainly Lisp systems have run in production for decades on
machines with much less memory than we would consider acceptable these
days for any substantial Python app.

It's probably true that gc copying-style gc is more memory hungry than
Python's refcount system.  Mark-sweep gc should have comparable memory
consumption and better speed than refcounting, though less speed than

JHC (experimental Haskell compiler) recently started using a mixture of
gc and region inference.  It will be interesting to see how that works

More information about the Python-list mailing list