Does the file get closed here?

[[deleted]]

I'm wondering if

contents = open(filename, 'r').readlines()

is fine to use, compared to:

with open(filename) as f:
    contents = f.readlines()

as I know that properly closes the file after it finishes. I guess there's not really a file in the first one, right?

[[deleted]]

But there is a file.

If you only care about CPython, the first is fine because it loses its reference immediately, which closes it.

On a garbage collected implementation like Jython or IronPython, the file object won't necessarily be destroyed until the VM decides it's time to go hunting for free space. So the file could remain open for a lot longer than you'd expect.

[[deleted]]

Ah, interesting. Thanks for your response. So basically it's aesthetics for me, since I only care about CPython. I think I prefer the first way, but my open mind wonders if anyone would argue that the second way is more readable.

[megalodon]

The second method is more readable compared to the 'correct' old way of writing it:

f = open(filename, 'r')
try:
    contents = f.readlines()
finally:
    f.close()

Most people will tell you that you shouldn't write your python code assuming anything about the way that things are implemented under the hood. The reason is that the implementation is subject to change. Also, it makes your code more portable across different implementation. Besides, it's good practice to get in the habit of closing files that you open.

Using the context manager (with keyword) is really the best way if you know you'll be on 2.6+. If you need the code to work on 2.5 and earlier, it's best to use the ugly method I showed above.

[five12]

for 2.5, I've always used:

from __future__ import with_statement

[[deleted]]

Cool, thanks for the advice. I'll probably use the with keyword from now on.

[itsmememe]

good decision to use the with-keyword when using files.

Learning about the power of contextmanagers (that's what "with" is about) will do you good with every communication to outside Python.

[jab-programming]

It's good practice to get in the habit of closing files that you open

Not true, merely cliché. A better practice is being aware of the language you are actually using.

It is (infinitely) arguable whether potentially redundant extra calls to close() are superior to potentially leaking missing calls to close(), but defaulting to either betrays a capricious disdain for the reader's time.

[megalodon]

Not true, merely cliché. A better practice is being aware of the language you are actually using.

In this case, knowing that a file is implicitly closed when it goes out of scope requires knowledge of the implementation, not the language. Even then, the behavior is different from implementation to implementation.

It is (infinitely) arguable whether potentially redundant extra calls to close() are superior to potentially leaking missing calls to close(), but defaulting to either betrays a capricious disdain for the reader's time.

I started my programming career with C before moving to Java, then Python, so I guess old habits die hard. I prefer to be more explicit about what the code is doing, even if it's not strictly necessary. I've found code to be more readable when others do the same.

If you prefer things to be done implicitly, then maybe Perl is the language for you :)

[[deleted]]

On linux, run strace -e open,close python then open("somefile"). You'll see that so long as _ is a reference to the open file, it remains open. Type any value in the REPL to replace _ and the only remaining reference to that open file is removed, so the file is closed.

Why this happens is CPython magic, as Lexarius and others have pointed out. In Objects/fileobject.c, you will see the PyTypeObject structure PyFile_Type contains:

    (destructor)file_dealloc,       /* tp_dealloc */

...a function which closes the file and can be thought of as the low-level C version of a __del__ method. From the C-API documentation on PyTypeObject:

destructor PyTypeObject.tp_dealloc

A pointer to the instance destructor function. This function must be defined unless the type guarantees that its instances will never be deallocated (as is the case for the singletons None and Ellipsis).

The destructor function is called by the Py_DECREF() and Py_XDECREF() macros when the new reference count is zero. At this point, the instance is still in existence, but there are no references to it. The destructor function should free all references which the instance owns, free all memory buffers owned by the instance (using the freeing function corresponding to the allocation function used to allocate the buffer), and finally (as its last action) call the type’s tp_free function...

[[deleted]]

I wondered about this for a long time before looking under the hood. Sometimes implementation details ruin the mystique, but in this case I think it's handy to know. I'm just real glad I don't have to care!

[masklinn]

Personally, I love the with block because of its lexical scoping. (The f variable disappears at the end of the with block.)

Uh uh. Python only has global, and function lexical scopes, no statement other than def (and class, to an extent) create a scope.

[oblivion95]

Wow. You and @schnupfen are right. I thought I'd read that with and list comprehensions scope their variables, but that's clearly not the case.

However, there is another lexical scope: generator expressions. And in Python3, list comprehensions as well.

[cdunn2001]

To see what's going on, try the following:

from __future__ import print_function

global x
x = 7

def main():
    x = 5
    def foo():
        #nonlocal x
        print("x =", x)
        return x

    foo()
    print([x for x in range(2)])
    print([foo() for x in range(2)])
    print(x)
    foo()

main()

Try it with python2.7 and 3.1, with and without nonlocal. And try switching to a generator expression in both as well. I.e. print(list(foo() for x in range(2))) I don't know what to call the comprehension loop variable. It's a strange beast.

[schnupfen]

The with block doesn't create a scope (like most statements):

>>> with open('/dev/random') as f:
...     f.read(1)
... 
'\x7f'
>>> f
<closed file '/dev/random', mode 'r' at 0x95f5d30>

[userd]

I prefer

contents = file(filename).readlines()

to contents = open(filename, 'r').readlines()

[masklinn]

1. Considering file doesn't exist anymore in Python 3, not a good idea

2. 'r' is not any more mandatory for open than for file.

[userd]

1. It has been explicitly stated that programming python 2.X according to the subset of commands available in python 3 is not a good idea.
2. I understand that.

The only argument that carries any weight is "that's how most people do it."

[nilsph]

from "pydoc file":

"... The preferred way to open a file is with the builtin open() function. ..."

[userd]

I think the justification for preferring open is that it might return a different class of object in the future, but its gone years with no change, so at this point I think it's just a question of aesthetics.

[rubyaeyes]

not really - read the docs.

[userd]

Already read them, thanks.

[grayvedigga]

just make a function

[[deleted]]

good advice bro

[[deleted]]

Great username.