[Python-Dev] PEP 279 (original) (raw)

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