[Python-Dev] PEP 279

Guido van Rossum guido@python.org
Thu, 28 Mar 2002 16:55:15 -0500


PEP 279 proposes three separate things.  Comments on each:


1. New builtin: indexed()

   I like the idea of having some way to iterate over a sequence and
   its index set in parallel.  It's fine for this to be a builtin.

   I don't like the name "indexed"; adjectives do not make good
   function names.  Maybe iterindexed()?

   I don't like the start and stop arguments.  If I saw code like

     for i, j in iterindexed("abcdefghij", 5, 10): print i, j

   I would expect it to print

     5 f
     6 g
     7 h
     8 i
     9 j

   while the spec in the PEP would print

     5 a
     6 b
     7 c
     8 d
     9 e

   Very confusing.  I propose to remove the start/stop arguments, *or*
   change the spec to:

     def iterindexed(sequence, start=0, stop=None):
         i = start
         while stop is None or i < stop:
             try:
                 item = sequence[i]
             except IndexError:
                 break
             yield (i, item)
             i += 1

   This reduces the validity to only sequences (as opposed to all
   iterable collections), but has the advantage of making
   iterindexed(x, i, j) iterate over x[i:j] while reporting the index
   sequence range(i, j) -- not so easy otherwise.

   The simplified version is still attractive because it allows
   arbitrary iterators to be passed in:

     def iterindexed(collection):
       i = 0
       it = iter(collection)
       while 1:
         yield (i, it.next())
         i += 1


2. Generator comprehensions

   I don't think it's worth the trouble.  I expect it will take a lot
   of work to hack it into the code generator: it has to create a
   separate code object in order to be a generator.  List
   comprehensions are inlined, so I expect that the generator
   comprehension code generator can't share much with the list
   comprehension code generator.  And this for something that's not
   that common and easily done by writing a 2-line helper function.
   IOW the ROI isn't high enough.


3. Generator exception passing

   This is where the PEP seems weakest.  There's no real motivation
   ("This is a true deficiency" doesn't count :-).  There's no hint as
   to how it should be implemented.  The example has a "return log"
   statement in the generator body which is currently illegal, and I
   can't figure out to where this value would be returned.  The
   example looks like it doesn't need a generator, and if it did, it
   would be easy to stop the generator by setting a global "please
   stop" flag and calling next() once more.  (If you don't like
   globals, make the generator a method of a class and make the stop
   flag an instance variable.)


--Guido van Rossum (home page: http://www.python.org/~guido/)