diff --git a/CHANGES.current b/CHANGES.current
index 15d58739f..e6dc1bebd 100644
--- a/CHANGES.current
+++ b/CHANGES.current
@@ -23,6 +23,29 @@ Unreleased changes
 	      The difference is that map.iterator() returns a safe
 	      'close' iterator, while map.begin() and map.end() are
 	      'open' iterators.
+
+	      A 'close' iterator knows the begin and the end of the
+	      sequence, and it never can seg. fault. A 'open'
+	      iterator, as in C++, can seg. fault at the C++ side.
+
+	         # a close iterator is safe in the following example.
+		 # the next() method will throw a StopIteration
+	         # exception as needed
+	
+	         i = seq.iterator()
+		 try:
+                      while True:
+		        sum += i.next()
+		 except: pass
+		 
+		 # an open iterator always need to be checked,
+		 # or it will crash at the C++ side
+
+	         current = seq.begin()
+                 end = seq.end()
+		 while (current != end):
+		    sum += current.next()
+	      
 	      
 	    [Python]
 	    - Finally, when we call 
@@ -58,12 +81,36 @@ Unreleased changes
 	      calling __init__ and it doesn't go 'back' to python, is
 	      'pure' C API.
 
-	     - With the above change, and the other changes in the
+	     - With this change, and the other ones in the
                PySwigObject type, which now carries the thisown and
-               swig_type_info pointer, we should be as fast as
-               boost::Python and/or the other python wrappers based in
-               pure Python/C API calls.
+               swig_type_info pointer, the generated code shoudl be as
+               fast as boost::Python and/or the other python wrappers
+               based in pure Python/C API calls.
 
+	       As a reference, the profiletest_runme.py example, which
+	       does a simple call function many times:
+
+                    import profiletest       
+		                             
+		    a = profiletest.A()      
+		    b = profiletest.B()      
+		    for i in range(0,1000000)
+	              a = b.fn(a)            
+
+
+	       where fn is defined as 'A* B::fn(A *a) {return a;}',
+	       produces  the following times
+
+                               nomodern    modern
+	         swig-1.3.26    25.9s       7.6s
+                 swig-CVS        3.4s       3.3s
+	       
+
+	       Clearly, there is a large improvement for the python
+	       'nomodern' mode. Still, the 'modern' mode is around
+	       twice faster than before.
+
+	       
 		  	      
 10/31/2005: mmatus
 	    [Python]
@@ -184,6 +231,22 @@ Unreleased changes
 		      print sum
 		      >>> "ac"
 		      
+            *** POTENTIAL INCOMPATIBILITY ***
+
+	    There is no more 'thisown' attribute. If you use it, you
+	    need to change as follows:
+
+                if (self.thisown):   ==>   if (self.this.own()):
+		self.thisown = 1     ==>   self.this.acquire()
+                self.thisown = 0     ==>   self.this.disown()
+
+            if you really really like the old 'thisown' attribute, you
+	    can submit a patch to treat it as a property, and dispatch
+	    the new method calls. Of course, before you try, it needs
+	    to work with old and new python versions, and with classic
+	    and modern python classes.
+	    
+	    
 
 10/30/2005: mkoeppe 
 	    [Guile] Make declared and defined linkage of SWIG_init consistent.