Does python guarantees that file.write() works without file.close() ?

[kryptomatrix]

Long story short: Is it guaranteed, that "out.txt" will contain "abc" after executing the following program:

f = open("out.txt", "w")
f.write("abc\n")

I'm not sure, whether the Standard guarantees if the file destructor flushes the file.

[buran]

use with context manager

with open("out.txt", "w") as f:
    f.write("abc\n")

it will close it for you

from the docs:

It is good practice to use the with keyword when dealing with file objects. The advantage is that the file is properly closed after its suite finishes, even if an exception is raised at some point. Using with is also much shorter than writing equivalent try-finally blocks:

>>>

>>> with open('workfile') as f:
...     read_data = f.read()

>>> # We can check that the file has been automatically closed.
>>> f.closed
True

If you’re not using the with keyword, then you should call f.close() to close the file and immediately free up any system resources used by it. If you don’t explicitly close a file, Python’s garbage collector will eventually destroy the object and close the open file for you, but the file may stay open for a while. Another risk is that different Python implementations will do this clean-up at different times.

[perfringo]

Is it guaranteed, that "out.txt" will contain "abc"

Only taxes and death are guaranteed, everything else is optional .

In more serious note - this 'guarantee' can't be given as there might be another processes which can overwrite the file. Yes, 'abc' will be written into file but this is not the same that 'guaranteed to contain' in some point after the writing.

[kryptomatrix]

Is it guaranteed, that "out.txt" will contain "abc"

Only taxes and death are guaranteed, everything else is optional .

In more serious note - this 'guarantee' can't be given as there might be another processes which can overwrite the file. Yes, 'abc' will be written into file but this is not the same that 'guaranteed to contain' in some point after the writing.

I'm assuming that no other process messes with it. The question is whether this script is guaranteed to write, because the following script does not write into the file:

from sympy.core import AtomicExpr

class MyWeirdClass(AtomicExpr):
	def __init__(self):
		pass

f = open("out.txt", "w")
f.write("abc\n")

I am looking for a point in the official specification that says whether this is guaranteed to write or not. Because if it is guaranteed to write, this is a bug in python.

use with context manager

with open("out.txt", "w") as f:
    f.write("abc\n")

it will close it for you

from the docs:

It is good practice to use the with keyword when dealing with file objects. The advantage is that the file is properly closed after its suite finishes, even if an exception is raised at some point. Using with is also much shorter than writing equivalent try-finally blocks:

>>>

>>> with open('workfile') as f:
...     read_data = f.read()

>>> # We can check that the file has been automatically closed.
>>> f.closed
True

If you’re not using the with keyword, then you should call f.close() to close the file and immediately free up any system resources used by it. If you don’t explicitly close a file, Python’s garbage collector will eventually destroy the object and close the open file for you, but the file may stay open for a while. Another risk is that different Python implementations will do this clean-up at different times.

I know the with keyword, but that wasn't the question. The question was if the standard guarantees that the my weird code works.

[snippsat]

The question was if the standard guarantees that the my weird code works.

No,it will depend on how run the file and what's used eg some editor may write and other not.
Running from command line it will work as it just open the interpreter and close it.

C:\code\read
λ python test_write.py

C:\code\read

If i now do the same but open it in interactive shell.

C:\code\read
λ python -i test_write.py
>>> s = 'hello'
>>> s.upper()
'HELLO'
>>>
>>> f
<_io.TextIOWrapper name='out.txt' mode='w' encoding='cp1252'>
>>>
>>> # As long as interpreter is running it will not write

Now noting get written,i have to close interpreter first.

>>> exit() # Only now will it write to file

C:\code\read

with open has been the preferred way since it come out in Python 2.5.

[kryptomatrix]

The question is, whether it is guaranteed to write when exit() is called (or earlier).

[snippsat]

The question is, whether it is guaranteed to write when exit() is called (or earlier).

No it's not guaranteed at all,it will fail in many cases as eg trying running in editors and not command line.
If i test in my editors will not write to file,dot not matter if i use exit() or close down the editor.
As long as the file object is open and not used it can be garbage collected.

To be sure has to use close().

f = open("out.txt", "w")
f.write("abc\n")
f.close()

Or better.

with open("out.txt", "w") as f:
    f.write("abc\n")

[kryptomatrix]

Is it guaranteed, that "out.txt" will contain "abc"

Only taxes and death are guaranteed, everything else is optional .

In more serious note - this 'guarantee' can't be given as there might be another processes which can overwrite the file. Yes, 'abc' will be written into file but this is not the same that 'guaranteed to contain' in some point after the writing.

The question is, whether it is guaranteed to write when exit() is called (or earlier).

No it's not guaranteed at all,it will fail in many cases as eg trying running in editors and not command line.
If i test in my editors will not write to file,dot not matter if i use exit() or close down the editor.
As long as the file object is open and not used it can be garbage collected.

To be sure has to use close().

f = open("out.txt", "w")
f.write("abc\n")
f.close()

Or better.

with open("out.txt", "w") as f:
    f.write("abc\n")

Thank you. The standard is phrased a bit ambiguously.