in the case of [iter(items)]*3 we are just copying the reference to the iterator so this has a much better memory footprint. I think that this is quite elegant actually.

Note that the list doesn't really have to be a multiple of 3 as zip will halt when it can't grab the next element from all zip'd iterators. I.e. if the list is of size 5 only the first group of three is returned.

Hi Brian, Naveen, Leonardo; I still think that this is no more than a trick, or at best it may become a design pattern but if it is of use then it should be replaced by an itertools function that has the functionality without having to worry about the awful code within it.It is mech worse than, say, when we had to use dict keys as sets; or the explicit decorate-sort-undecorate pattern.

I thought it would be worth mentioning that for practical use, there are other worthy solutions to the chunking problem. There are two downsides to the iter/zip approach. First, it's hard to understand, and second, if the number of items is not a multiple of the chunk size, not all items appear in the output. (The latter will be fine in some situations, and undesirable in others.)

This solution is significantly easier to understand, and outputs every input item. When the items are not multiple of the chunk size, the output groups are as similar in size as possible:

Of course, kudos for the in-depth analysis.. but maybe a more appropriate title would be "That grouping by zip/iter trick.. and why you shouldn't use it".. I only just saw the part at the bottom of your post saying "this is useless due to equal sizes".

Hi Cal, I did think about the title and wanted to encourage more to read it so made sure the word 'trick' was in there as I thought it would attract more readers. I left the "don't use me" to the end for a similar reason, I thought it might be a barrier to potential readers.

Your suggestion _is_ more informative, but is it a better _title_ for a blog entry for a (little) vain person who does want some readership?