to close or not to close?

[Alex Martelli]

"Grant Edwards" <ge at nowhere.none> wrote in message
news:TDBh5.3026$6E.842685 at ptah.visi.com...
    [snip]
> >Python provides both reliably-called destructors (at least in
> >CPython it does; the JPython or .NET dialects may work
> >differently), _and_ try/finally, so there is really no 'pull'
> >from the language itself towards one or the other idiom.
>
> I think we're loosing one of the big advantages of Python if
> users can't rely on objects "going away" when they're no longer
> used and instead have to explicitly free() them.  The current
> reference-counting problem that CPython has with circular
> references is something I can live.  Having to explicitly
> dispose of objects when I'm done with them would completely
> ruin the "feel" of the language.

The need to call an explicit .close(), or whatever, really only
applies to objects which are encapsulating/owning a scarce
resource -- an open file, a database connection, something
like that.  As I said, I like the automatic-destruction-idiom,
myself, and I dearly hope it's maintained (perhaps only when
explicitly requested; I do realize reference-counting to obtain
immediate reliable destruction is a costly approach if/when
one has good, "serious" GC going on anyway!) wherever it's
feasible to maintain it.  That much being said, I think your
worry on the subject might perhaps be excessive; the try/
finally idiom is in Python for a purpose (presumably, to offer
support to programmers that don't _want_ to have to wrap
every costly-resource into a class, with its release in the
destructor, but would rather be more explicit about those few
instances of costly-resource-acquisition-and-release).

I'd rather be able to wrap costly resources in specially
designed classes (e.g., ones inheriting from a hypothetical
sys.Release_ASAP class...?), as a compromise between
every class being release-ASAP and none being so, but, if
such a compromise should be technically unfeasible, I'll live
with garbage-collection-only, and try/finally, if and when those
are the prices to be paid for substantial benefits (increases
in performance, and/or coexistence in interesting environments,
such as JVM or the .Net Framework...).


Alex