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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4