Python vs Java garbage collection?

["Martin v. Löwis"]

Ganesan R wrote:
> I guess, that's really the key thing - _if_ you are aware of all the finer
> points. This is assuming "int" is 32-bits in C. You know for in most current
> hardware "int" is 32-bits, you know that "int" is 32-bits in most 64-bit C
> implementations too. So there's really nothing "wrong" in that programming
> practise.

It turns out that relying on 32-bit ints is a much more serious problem 
for Python than relying on refcounting. People just *know* that 
0x80000000 is a negative number; an attempt to change this for Python 
2.4 turns out to be very difficult to implement without breaking too 
much code.

People have these assumptions in their code whether they are aware of 
them or not. This constrains language evolution, but I consider it a 
good thing: the language developers need to understand what hidden 
assumptions people rely on, and they need to make an explicit choice to 
break those assumption. When they do that, they need to find a way to 
either not break the existing code, or to give developers mechanisms to 
make the hidden assumptions visible. For Python, the mechanisms are 
documented in PEP 5.

> This programming practice ought to deprecated _unless_ the programmer is
> fully aware of what (s)he's doing. Take a module writer for example. He may
> not care about Jython and choose to depend on the finalizer. Yes, Jython may
> disappear tomorrow; but the fact is it's a reality today and there are many
> users out there using Jython.  Our fictional module writer might have
> rendered his module useless for Jython users today.

I find the Jython argument not very convincing. If people need to 
support both CPython and Jython, they have much bigger problems than 
finalizers. Most likely, some essential library they use is not 
available for Jython, so they have to actively test their application on 
Jython. They should also review their code, to find where they rely on 
finalizers, and perhaps make other, non-portable assumptions in it.

Regards,
Martin