- We really rely on the users to close the file handles correctly.

 - I made the IStreamIterator not gently close itself, but rely on e.g. Medusa
   closing it.
 - The tests now document the behaviour that a user should close the file handles.

branches/ctheune-blobsupport/src/ZODB/Blobs/Blob.py

@@ -190,8 +190,6 @@ class BlobFile(file):
     def next(self):
         data = self.read(self.streamsize)
         if not data:
-            if self.blob is not None:
-                self.blob._rc_decref(self.mode)
             raise StopIteration
         return data
 

branches/ctheune-blobsupport/src/ZODB/Blobs/Blob.txt

@@ -58,7 +58,7 @@ If we want to, we can open it again:
     >>> f3.read()
     'Hi, Blob!'
 
-But we can't  open it for writing, while it is opened for reading:
+But we can't open it for writing, while it is opened for reading:
 
     >>> myblob.open("a")
     Traceback (most recent call last):
@@ -78,8 +78,27 @@ Now we can open it for writing again and e.g. append data:
 
 Now we can read it:
 
+    >>> f4a = myblob.open("r")
+    >>> f4a.read()
+    'Hi, Blob!\nBlob is fine.'
+    >>> f4a.close()
+
+Please, always remember closing an opened blob, otherwise you might get
+blocked later on. Therefore you should avoid using the result of open()
+without binding it to a name:
+
     >>> myblob.open("r").read()
     'Hi, Blob!\nBlob is fine.'
+    >>> f4b = myblob.open("a")
+    Traceback (most recent call last):
+        ...
+    BlobError: Already opened for reading.
+    
+To clean that up, we have to commit or abort the current transaction, so the reference
+counters for opened blob files get to a valid state again:
+
+    >>> import transaction
+    >>> transaction.commit()
 
 We can read lines out of the blob too: