From 925514c52550dcafa90c9de4c1c822f339f55e1e Mon Sep 17 00:00:00 2001 From: Mark Pilgrim Date: Fri, 17 Jul 2009 15:24:09 -0400 Subject: [PATCH] finished #close section --- files.html | 115 +++++++++++++++++++++++++++++++---------------------- 1 file changed, 67 insertions(+), 48 deletions(-) diff --git a/files.html b/files.html index 7c2a0d9..864bb27 100644 --- a/files.html +++ b/files.html @@ -28,13 +28,14 @@ body{counter-reset:h1 12} 
a_file = open('examples/chinese.txt', encoding='utf-8')
-

Python has a built-in open() function, which takes a filename as an argument. Here the filename is 'examples/chinese.txt'. There are four interesting things about this filename: +

Python has a built-in open() function, which takes a filename as an argument. Here the filename is 'examples/chinese.txt'. There are five interesting things about this filename:

  1. It’s not just the name of a file; it’s a combination of a directory path and a filename. A hypothetical file-opening function could have taken two arguments — a directory path and a filename — but the open() function only takes one. In Python, whenever you need a “filename,” you can include some or all of a directory path as well.
  2. The directory path uses a forward slash, but I didn’t say what operating system I was using. Windows uses backward slashes to denote subdirectories, while Mac OS X and Linux use forward slashes. But in Python, forward slashes always Just Work, even on Windows.
  3. The directory path does not begin with a slash or a drive letter, so it is called a relative path. Relative to what, you might ask? Patience, grasshopper.
  4. It’s a string. All modern operating systems (even Windows!) use Unicode to store the names of files and directories. Python 3 fully supports non-ASCII pathnames. +
  5. It doesn’t need to be on your local disk. You might have a network drive mounted. That “file” might be a figment of an entirely virtual filesystem. If your computer considers it a file and can access it as a file, Python can open it.

But that call to the open() function didn’t stop at the filename. There’s another argument, called encoding. Oh dear, that sounds dreadfully familiar. @@ -92,47 +93,62 @@ UnicodeDecodeError: 'charmap' codec can't decode byte 0x8f in position 28: chara 

 >>> a_file = open('examples/chinese.txt', encoding='utf-8')
->>> a_file.read()
-'Dive Into Python 是为有经验的程序员编写的一本 Python 书。\n'
+>>> a_file.read() ① +'Dive Into Python 是为有经验的程序员编写的一本 Python 书。\n' +>>> a_file.read() ② +''
    -
  1. FIXME +
  2. Once you open a file (with the correct encoding), reading from it is just a matter of calling the file object’s read() method. The result is a string. +
  3. Perhaps somewhat surprisingly, reading the file again does not raise an exception. Python does not consider reading past end-of-file to be an error; it simply returns an empty string.
-

FIXME +

What if you want to re-read a file? 

->>> a_file.seek(0)
+# continued from the previous example
+>>> a_file.read()    ①
+''
+>>> a_file.seek(0)   ②
 0
->>> a_file.read(16)
+>>> a_file.read(16)  ③
 'Dive Into Python'
->>> a_file.read(1)
+>>> a_file.read(1)   ④
 ' '
->>> a_file.read(1)
+>>> a_file.read(1)   ⑤
 '是'
->>> a_file.tell()
+>>> a_file.tell()    ⑥
 20
  1. FIXME +
  2. +
  3. +
  4. +
  5. +

FIXME 

->>> a_file.seek(17)
+# continued from the previous example
+>>> a_file.seek(17)  ①
 17
->>> a_file.read(1)
+>>> a_file.read(1)   ②
 '是'
->>> a_file.tell()
+>>> a_file.tell()    ③
 20
  1. FIXME +
  2. +

FIXME 

->>> a_file.seek(18)
->>> a_file.read(1)
+>>> a_file.seek(18)                         ①
+18
+>>> a_file.read(1)                          ②
 Traceback (most recent call last):
   File "<pyshell#12>", line 1, in <module>
     a_file.read(1)
@@ -141,45 +157,48 @@ UnicodeDecodeError: 'charmap' codec can't decode byte 0x8f in position 28: chara
 UnicodeDecodeError: 'utf8' codec can't decode byte 0x98 in position 0: unexpected code byte
  1. FIXME +
-

6.2.2. Closing Files

+

Closing Files

Open files consume system resources, and depending on the file mode, other programs may not be able to access them. It’s important to close files as soon as you’re finished with them. - +

+# continued from the previous example
+>>> a_file.close()
-

FIXME checking if a file is closed +

Well that was anticlimactic. + +

The file object a_file still exists; calling its close() method doesn’t destroy the object itself. But it’s not terribly useful. + +

+# continued from the previous example
+>>> a_file.read()                           ①
+Traceback (most recent call last):
+  File "<pyshell#24>", line 1, in <module>
+    a_file.read()
+ValueError: I/O operation on closed file.
+>>> a_file.seek(0)                          ②
+Traceback (most recent call last):
+  File "<pyshell#25>", line 1, in <module>
+    a_file.seek(0)
+ValueError: I/O operation on closed file.
+>>> a_file.tell()                           ③
+Traceback (most recent call last):
+  File "<pyshell#26>", line 1, in <module>
+    a_file.tell()
+ValueError: I/O operation on closed file.
+>>> a_file.close()                          ④
+>>> a_file.closed                           ⑤
+True
+
    +
  1. You can’t read from a closed file; that raises an IOError exception. +
  2. You can’t seek in a closed file either. +
  3. There’s no current position in a closed file, so the tell() method also fails. +
  4. Perhaps surprisingly, calling the close() method on a file object whose file has been closed does not raise an exception. It’s just a no-op. +
  5. Closed file objects do have one useful attribute: the closed attribute will confirm that the file is closed. +

Using The with Statement