Skip to content

bpo-17852: Fixed the documentation about closing files #23135

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
methane merged 8 commits into from
Nov 27, 2020
Merged

bpo-17852: Fixed the documentation about closing files #23135

Changes from 5 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
8bf4953
Fixed the documentation of the open() command
Volker-Weissmann Nov 3, 2020
8e599a5
Simple documentation fix
Volker-Weissmann Nov 3, 2020
44ddcd4
Simple documentation fix
Volker-Weissmann Nov 3, 2020
9f1456d
Removed trailing whitespace
Volker-Weissmann Nov 3, 2020
8cb45d4
Simple documentation fix
Volker-Weissmann Nov 5, 2020
05e1133
Applied suggestion vom methane
Volker-Weissmann Nov 7, 2020
f2c47bc
Merge branch 'documentation_of_open' of https://github.com/Volker-Wei…
Volker-Weissmann Nov 7, 2020
f4bbc4f
Update Doc/tutorial/inputoutput.rst
Volker-Weissmann Nov 13, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 24 additions & 5 deletions Doc/tutorial/inputoutput.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -329,11 +329,30 @@ equivalent :keyword:`try`\ -\ :keyword:`finally` blocks::

If you're not using the :keyword:`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.
resources used by it. :meth:`__del__` of the returned :term:`file object` also calls ``f.close()``.
Comment thread
methane marked this conversation as resolved.
Outdated

..
Source for the claim that the ``del(f)`` calls .close():
Take a look at the source code of open() in _pyio.py and check the
returned type. It will always be one of these 5 classes:
FileIO
TextIOWrapper
BufferedRandom
BufferedWriter
BufferedReader
FileIO defines the __del__ method that calls .close().
The other 4 classes inherit indirectly (without overwriting __del__) from
IOBase which defines the __del__ method that calls .close().

.. warning::
Calling ``f.write()`` without using the :keyword:`!with` keyword or calling
``f.close()``, ``f.flush()`` or ``del f`` **might** result in the arguments
Comment thread
Volker-Weissmann marked this conversation as resolved.
Outdated
of ``f.write()`` not being completely written to the disk, even if the
program exists successfully. This is because Python does not guarantee that
:meth:`__del__` is called when the interpreter exists.
Comment thread
methane marked this conversation as resolved.
Outdated
Comment thread
methane marked this conversation as resolved.
Outdated

..
See also https://bugs.python.org/issue17852

After a file object is closed, either by a :keyword:`with` statement
or by calling ``f.close()``, attempts to use the file object will
Expand Down