Python's "only one way to do it" philosophy isn't good?

[Chris Mellon]

On 7/2/07, Douglas Alan <doug at alum.mit.edu> wrote:
> Lenard Lindstrom <len-l at telus.net> writes:
> > If they are simply a performance tweak then it's not an issue *. I
> > was just concerned that the calls were necessary to keep resources
> > from being exhausted.
>
> Well, if you catch an exception and don't return quickly, you have to
> consider not only the possibility that there could be some open files
> left in the traceback, but also that there could be a large and now
> useless data structures stored in the traceback.
>
> Some people here have been arguing that all code should use "with" to
> ensure that the files are closed.  But this still wouldn't solve the
> problem of the large data structures being left around for an
> arbitrary amount of time.
>

I don't think anyone has suggested that. Let me be clear about *my*
position: When you need to ensure that a file has been closed by a
certain time, you need to be explicit about it. When you don't care,
just that it will be closed "soonish" then relying on normal object
lifetime calls is sufficient. This is true regardless of whether
object lifetimes are handled via refcount or via "true" garbage
collection. Relying on the specific semantics of refcounting to give
certain lifetimes is a logic error.

For example:

f = some_file() #maybe it's the file store for a database implementation
f.write('a bunch of stuff')
del f
#insert code that assumes f is closed.

This is the sort of code that I warn against writing.

f = some_file()
with f:
  f.write("a bunch of stuff")
#insert code that assumes f is closed, but correctly this time

is better.

On the other hand,
f = some_file()
f.write("a bunch of stuff")
#insert code that doesn't care about the state of f

is also fine. It *remains* fine no matter what kind of object lifetime
policy we have. The very worst case is that the file will never be
closed. However, this is exactly the sort of guarantee that GC can't
make, just as it can't ensure that you won't run out of memory. That's
a general case argument about refcounting semantics vs GC semantics,
and there are benefits and disadvantages to both sides.

What I am arguing against are explicit assumptions based on implicit
behaviors. Those are always fragile, and doubly so when the implicit
behavior isn't guaranteed (and, in fact, is explicitly *not*
guaranteed, as with refcounting semantics).