[Python-checkins] CVS: python/nondist/peps pep-0279.txt,1.6,1.7

[Barry Warsaw]

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv30928

Modified Files:
	pep-0279.txt 
Log Message:
One more update from Raymond Hettinger.



Index: pep-0279.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0279.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** pep-0279.txt	11 Mar 2002 17:33:49 -0000	1.6
--- pep-0279.txt	11 Mar 2002 19:31:23 -0000	1.7
***************
*** 52,56 ****
      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
         to dictionaries -- a compact, readable, reliable index notation.
         
--- 52,56 ----
      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 iteritems() affords
         to dictionaries -- a compact, readable, reliable index notation.
         
***************
*** 160,163 ****
--- 160,169 ----
          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.
***************
*** 243,246 ****
--- 249,257 ----
          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
***************
*** 262,266 ****
              try:
                  while 1:0
!             log.append( time.time() - start )
                      yield log[-1]
              except WriteLog:
--- 273,277 ----
              try:
                  while 1:0
!                     log.append( time.time() - start )
                      yield log[-1]
              except WriteLog:
***************
*** 321,325 ****
          passing of values back, then we should add this feature too.
  
!     Author response:  If 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
--- 332,339 ----
          passing of values back, then we should add this feature too.
  
!     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
***************
*** 462,465 ****
--- 476,486 ----
          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,483 ****
--- 501,507 ----
          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