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

Falcolas garrickp at gmail.com
Thu Jul 5 20:17:58 CEST 2007


On Jul 5, 10:30 am, "Chris Mellon" <arka... at gmail.com> wrote:
>
> 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.

This has raised a few questions in my mind. So, here's my newbie
question based off this.

Is this:

f = open(xyz)
f.write("wheee")
f.close()
# Assume file is closed properly.

as "safe" as your code:

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

Thanks!

G




More information about the Python-list mailing list