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
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