This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: itertools should grow chunkify
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: arkanes, rhettinger
Priority: normal Keywords:

Created on 2007-11-26 23:42 by arkanes, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
chunkify.patch arkanes, 2007-11-26 23:42
Messages (2)
msg57861 - (view) Author: Chris Mellon (arkanes) Date: 2007-11-26 23:42
One of the most common requests in c.l.p and #python is a way to break
an iterable up into some particular size chunks. For example, "abcdef"
-> "ab", "cd", "ef". It's pretty easy to write one, but there are a few
subtleties to it (like if you want padding or partial results) and it's
so common that having it in the stdlib would be nice.

Attached is a patch which implements itertools.chunkify. It can
optionally discard, pad, or return any leftovers in the source iterable.
Tests and docstrings are included, but it needs to be documented in the
manual. One thing it does not do, but maybe it should, is guess what
type the yielded values should have based on the input sequence - it
always returns lists.

Patch is against trunk, r59186.
msg57862 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-11-27 00:22
Sorry, this has been proposed and rejected previously.  One of the 
reasons was that the docs already have a C-speed recipe, grouper(), 
that shows how to do it with padding and it is even simpler to do it 
without padding using only zip() or izip().  Another was a lack of 
compelling use cases.  It was more fun to write and discuss than 
actually use in real code.

Also, I'm not happy with the given implementation.  The name is weak 
and the "partial" argument complexifies the function (its often better 
to have separate function than two combine two behaviors with a flag 
variable).

Even if cleaned-up and a use case or two is demonstrated, am not 
willing to clutter the module with more functions like this.

That being said, I do want to compliment the submission of a working 
patch with unittests.  Nice work.
History
Date User Action Args
2022-04-11 14:56:28adminsetgithub: 45843
2007-11-27 00:22:29rhettingersetstatus: open -> closed
assignee: rhettinger
resolution: rejected
messages: + msg57862
nosy: + rhettinger
2007-11-26 23:42:24arkanescreate