Python's "only one way to do it" philosophy isn't good?
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.
f = open(xyz)
# Assume file is closed properly.
as "safe" as your code:
f = some_file()
f.write("a bunch of stuff")
#insert code that assumes f is closed, but correctly this time
More information about the Python-list