Possible Duplicate:
Is there a map without result in python?
I often come to a situation in my programs when I want to quickly/efficiently call an in-place method on each of the items contained by an iterable. (Quickly meaning the overhead of a for loop is unacceptable). A good example would be a list of sprites when I want to call draw()
on each of the Sprite
objects.
I know I can do something like this:
[sprite.draw() for sprite in sprite_list]
But I feel like the list comprehension is misused since I'm not using the returned list. The same goes for the map
function. Stone me for premature optimization, but I also don't want the overhead of the return value.
What I want to know is if there's a method in Python that lets me do what I just explained, perhaps like the hypothetical function I suggest below:
do_all(sprite_list, draw)
You can always write your own do_all
function:
def do_all(iterable, func):
for i in iter(iterable):
func(i)
Then call it whenever you want.
There is really no performance problem with using an explicit for
loop.
There is a performance problem with using a list comprehension or map
, but only in building the list of results. Obviously, iterating over 500M items will be a lot slower if you have to build up a 500M list along the way.
It's worth pointing out here that this is almost certainly not going to arise for things like drawing a list of sprites. You don't have 500M sprites to draw. And if you do, it'll probably take a lot longer than creating a list of 500M copies of None. And in most plausible cases where you do need to do the same very simple thing to 500M objects, there are better solutions, like switching to numpy
. But there are some conceivable cases where this could arise.
The easy way around that is to use a generator expression or itertools.imap
(or, in Python 3, just map
) and then dispose of the values by writing a dispose
function. One possibility:
def dispose(iterator):
for i in iterator:
pass
Then:
dispose(itertools.imap(Sprite.draw, sprite_list))
You could even define do_all
as:
def do_all(iterable, func):
dispose(itertools.imap(func, iterable))
If you're doing this for clarity or simplicity, I think it's misguided. The for loop version is perfectly easy to read, and this version looks like you're trying to write Haskell with the wrong function names and syntax.
If you're doing it for performance… well, if there were ever a real-life performance situation where this mattered (which doesn't seem very likely), you'd probably want to play with a bunch of different potential implementations of dispose
, and possibly move the dispose
back into the do_all
to avoid the extra function call, and maybe even implement the whole thing in C (borrowing the fast-iteration code from the stdlib's itertools.c).
Or, better, pip install more-itertools
, then use more_itertools.consume
. For what it's worth, the current version just does collections.deque(iterator, maxlen=0)
, and in a test against a custom C implementation, it's less than 1% slower (except for very tiny iterators—the cutoff is 19 on my system), so it's probably not worth implementing in C. But if someone does, or if some future Python (or PyPy) provides a faster way to implement it, chances are it'll be added into more-itertools
before you find out about it and change your code.