One more update from Raymond Hettinger.

pep-0279.txt

@@ -51,7 +51,7 @@ Rationale
 
     1. Add a new builtin function, indexed() which was made possible
        once iterators and generators became available.  It provides
-       all iterables with the same advantage that iteritem() affords
+       all iterables with the same advantage that iteritems() affords
        to dictionaries -- a compact, readable, reliable index notation.
        
     2. Establish a generator alternative to list comprehensions [3]
@@ -159,6 +159,12 @@ Specification for a new builtin:
         might be better off selling them as part of a module.  If you use a
         module then you can add lots of useful functions (Haskell has lots of
         them that we could steal).
+
+    Commentary for Magnus Lie Hetland:  I think indexed would be a useful and
+        natural built-in function. I would certainly use it a lot.
+        I like indexed() a lot; +1. I'm quite happy to have it make PEP 281
+        obsolete. Adding a separate module for iterator utilities seems like
+        a good idea.
     
     Author response:  Prior to these comments, four builtins were proposed.
         After the comments, xmap xfilter and xzip were withdrawn.  The one
@@ -242,6 +248,11 @@ Specification for Generator Comprehensions:
         comprehensions.  They don't seem to add much.  You could easily use
         a nested generator to do the same thing.  They smell like lambda.
 
+    Commentary for Magnus Lie Hetland:  Generator comprehensions seem mildly
+        useful, but I vote +0. Defining a separate, named generator would
+        probably be my preference. On the other hand, I do see the advantage
+        of "scaling up" from list comprehensions.
+
     Author response:  This may be before its time in that some people still
         don't like list comprehensions and half of this PEP's reviewers did
         not have any use for generators in any form.  What I like best about
@@ -261,7 +272,7 @@ Specification for Generator Exception Passing:
         log = []
             try:
                 while 1:0
-            log.append( time.time() - start )
+                    log.append( time.time() - start )
                     yield log[-1]
             except WriteLog:
                 return log
@@ -320,7 +331,10 @@ Specification for Generator Exception Passing:
         hadn't thought of before and looks interesting.  If we enable the
         passing of values back, then we should add this feature too.
 
-    Author response:  If the sole use of generators is to simplify writing
+    Commentary for Magnus Lie Hetland:  Even though I cannot speak for the
+        ease of implementation, I vote +1 for the exception passing mechanism.
+
+    Author response:  When the sole use of generators is to simplify writing
         iterators for lazy producers, then the odds of needing generator 
         exception passing are very slim.  If, on the other hand, generators
         are used to write lazy consumers, create coroutines, generate output
@@ -461,6 +475,13 @@ Specification for Generator Parameter Passing [Deferred Proposal]
         can work around this limitation by making your generator a method.
         Values can be passed back by mutating the instance.
 
+    Commentary for Magnus Lie Hetland:  I like the generator parameter
+        passing mechanism. Although I see no need to defer it, deferral seems
+        to be the most likely scenario, and in the meantime I guess the
+        functionality can be emulated either by implementing the generator 
+        as a method, or by passing a parameter with the exception
+        passing mechanism.
+
     Author response:  Okay, consider this part of the proposal deferred
         until 2.4.
 
@@ -480,6 +501,9 @@ Restartability
         reasonable that it might be good idea, though perhaps YAGNI will apply
         here until I experience the need for it first-hand.
 
+    Commentary for Magnus Lie Hetland:  I guess there is no real need to comment
+        on restartability, but I can't see that I have any need for it.
+
     Author response:  Over thirty reviewers responded, only one was interested
         in restartability on the theory that it made life easier for beginners
         and that it made lazy evaluation more substitutable for full