Python 2.0

[Donn Cave]

graham at sloth.math.uga.edu (Graham Matthews) writes:
| Donn Cave (donn at u.washington.edu) wrote:
|: You're in good company here, I think the leading lights of the Python
|: world all prefer explicit termination in these cases.  Ref counting sure
|: offers a great convenience here, though.  Files close and flush their
|: buffers, dialogues disappear, all in accordance with their programmatic
|: lifetime.  I personally will miss this finalization more than any resource
|: management if reference counting is taken away.
|
| You seem to believe that garbage collection implies no reference counts.
| Why do you believe that? (a lot of GC schemes use reference counts).
| You also seem to believe that with GC finalisation will disappear. Why
| do you believe that (a lot of GC schemes have finalisation).

Does JPython use reference counts, and invoke delete methods as soon as
reference count drops to 0?

| ... Finally I
| believe you are mis-using finalisation if you use it to close up files,
| sockets, etc. That's what close calls are for.

Well, I think there's something to be said for it.  With Python, we're
free from the obnoxious requirement imposed by the storage model of
languages like C, that forces the programmer to account for each scrap
of malloc'd memory lest there be leaks.  That allows me to export an
object reference (e.g., via function return) and forget about it, and
that has radically beneficial implications for how things can be structured.

Why should I enjoy this freedom with memory resources, but welcome exactly
the same constraints when an object has other termination requirements?

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu